Workflow recipes

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.

9:40

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.

1

Problem

Name the operating gap and the decision the team needs to make.

2

Data

Identify the records and fields Teambridge must trust.

3

Workspace

Create the queue where operators review and act.

4

Policy

Define what should be allowed, blocked, flagged, or ranked.

5

Workflow

Connect triggers, conditions, messages, updates, and approvals.

6

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
Teambridge scheduling product visual showing shift coverage workflow

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

1

Admin creates facility access group.

2

Admin enables only required app access.

3

Admin makes Schedule and Shifts visible.

4

Admin configures collection and field permissions.

5

Admin applies location-based data filters.

6

Facility user creates or updates a shift.

7

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