Workflow recipe

Control overtime

This recipe explains how to evaluate overtime risk before a worker is approved for more work. Some clients require a hard block. Others want a warning and manager review. Teambridge should make that decision explicit, auditable, and visible before payroll is affected.

Operational question

Would this shift push the worker into overtime, and should the system block it or route it for review?

Reference walkthrough

Auto-reject overtime

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.

2:29

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 worker status, role, location, and weekly hour context.
Shifts with start time, end time, assignee, requested worker, and scheduled hours.
Timesheets with worked hours, approved hours, and pay-period boundaries.
Locations or clients with overtime preference: block, flag, allow, or review.
Policy result fields such as Overtime Risk, Reject Reason, or Needs Review.

Product example

What time review looks like when clock-ins and exceptions are part of the same record.

This supports time, attendance, payroll readiness, overtime, and exception sections because those workflows depend on trusted shift and timecard signals.

Open time tracking product page

Teambridge time tracking product visual showing a timecard workflow

Workspace design

Shift Requests tab for pending worker requests.
Overtime Risk tab for requests that need review.
Rejected Requests tab for blocked actions and audit review.
Approved Exceptions tab for overtime that was intentionally allowed.
Payroll Review tab for records where overtime affects pay or bill outcome.

Rules and policy logic

Calculate current worked or scheduled hours against the pay-period threshold.
Evaluate the requested shift duration before approval.
Apply client or location-specific rules.
Use hard rejection only when the rule is clear.
Use flagging when business judgment is still needed.

Workflow sequence

How the process should run

Worker requests or claims a shift.

Teambridge calculates total hours if the shift is accepted.

Policy checks the worker, shift, location, and client rule.

If blocked, the worker receives a rejection message and the request is logged.

If flagged, the request appears in an admin review workspace.

Admin approves, denies, or assigns a different worker.

Final decision is stored for audit and payroll context.

Testing checklist

Test a worker below threshold.
Test a worker who crosses threshold with the requested shift.
Test a client that blocks overtime.
Test a client that only flags overtime.
Confirm rejected and approved-exception records are visible to admins.

Common failure modes

The rule reads scheduled hours but payroll uses approved worked hours.
Every overtime case is blocked even when some clients allow exceptions.
The worker sees a rejection without a useful explanation.
Admins cannot find rejected or flagged requests later.
Overtime data is not available to payroll review.