Workflow recipe
Client and facility access
This recipe explains how to let clients or facilities participate in operations without giving them internal admin access. They may need to create shifts, view schedules, submit surveys, or manage their location, but they should not see sensitive account data.
Operational question
How can a facility collaborate directly while only seeing and editing its own operational scope?
Reference walkthrough
Facility access groups
Use the video as a visual reference, then use the sections below to understand the actual implementation model: data, workspaces, rules, workflow steps, tests, and common failure modes.
Implementation model
Build the workflow in the same order the operation will depend on it.
A recipe is complete only when the business problem, data model, operator view, policy decision, automated follow-up, and testing path all line up.
Problem
Name the operating gap and the decision the team needs to make.
Data
Identify the records and fields Teambridge must trust.
Workspace
Create the queue where operators review and act.
Policy
Define what should be allowed, blocked, flagged, or ranked.
Workflow
Connect triggers, conditions, messages, updates, and approvals.
Test
Run realistic pass, fail, exception, and permission scenarios.
Data model
- Users with access group and associated location.
- Locations linked to facility or client users.
- Shifts linked to locations and containing fields the facility can view or update.
- Optional survey records linked to facility, shift, worker, or quality category.
- Schema permissions for sensitive fields such as rates, internal notes, or admin-only status.
Product example
What schedulers see when open shifts, rules, and worker response come together.
This is useful context for the scheduling sections because it shows the operational surface operators use to move from open work to confirmed coverage.
Open scheduling product page
Workspace design
- Facility Schedule workspace visible to scoped users.
- Facility Shifts workspace for creating or updating shifts.
- Survey or Feedback workspace if facilities submit quality information.
- Internal Admin workspace where Teambridge staff review client-created demand.
- Audit workspace for changes made by client or facility users.
Rules and policy logic
- Facility users can access the web app only if needed.
- Visible pages should be limited to the facility workflow.
- Data filters should restrict records by associated location.
- Field permissions should hide sensitive user, pay, bill, and configuration data.
- Testing must happen from a real facility user account.
Workflow sequence
How the process should run
Admin creates facility access group.
Admin enables only required app access.
Admin makes Schedule and Shifts visible.
Admin configures collection and field permissions.
Admin applies location-based data filters.
Facility user creates or updates a shift.
Internal team reviews demand and fulfills coverage.
Testing checklist
- Create a facility test user linked to one location.
- Confirm the user only sees Schedule/Shifts pages.
- Confirm the user only sees shifts for their location.
- Try creating, updating, and deleting a shift if allowed.
- Confirm hidden fields are not visible in list or detail views.
Common failure modes
- Facility users receive owner-like access because it is faster.
- Workspace access is scoped but data filters are missing.
- Field permissions expose rates or internal notes.
- Facility-created shifts bypass internal review.
- No test user is used before inviting real clients.
Related documentation
Back to recipe index