← Help

Crew operations

Crew availability, private documents and expiry reminders

Product documentation · Reviewed

Open Crew & inventory → Open crew scheduling, then the person’s Working availability & private documents link. Current workspace owners, administrators and staff with full private access can manage these records. Limited collaborators and holders of a shift link cannot read the files or review notes.

Record the hours someone can work

Not recorded preserves the existing role, time-off and reservation rules. It is not a statement that the person confirmed unrestricted availability. Choose Only the working windows below to constrain new assignments and appointment staff reservations to an explicit schedule.

Set an IANA timezone, a start date and a last date. A policy covers at most two years. Add weekly day-and-time windows; select Ends next day for overnight work. Adjacent windows can cover one continuous assignment. A gap between them cannot be used as working time. Date overrides replace the weekly occurrences beginning on that date. An override with no windows means no occurrence starts that day; an overnight occurrence beginning the previous day can still continue into it.

For example, Harper can work Monday through Friday from 09:00 to 17:00 in America/Los_Angeles. A 09:00 appointment requiring 30 minutes of protected travel before its start does not fit: the complete reserved interval begins at 08:30. Record the earlier working window only if Harper is actually available then. The service checks the full buffer and travel interval selected by scheduling.

A missing or repeated local time during a daylight-saving clock change is held for review. Choose an unambiguous time or a date override; the system does not silently select one of two offsets. An assignment outside the effective policy dates also needs review.

Select Review availability change to inspect affected future assignments and existing appointment reservations. Apply reviewed availability saves an immutable policy revision. An affected unworked crew assignment becomes held; resolving its eligibility moves it to Needs reconfirmation, preserving the earlier acceptance in history. Existing appointments remain saved and reserved. Their warnings appear here and must be resolved through scheduling; this screen does not cancel them.

Define a document requirement for your business

Add a named type, such as Audio team coverage record, and the crew roles it applies to. Leaving roles blank applies it to all roles. Choose whether it is required for assignments and whether its original must have a recorded expiry. These are your business’s scheduling rules, not a certification or legal eligibility determination.

Requirements belong to the active business. Their saved changes recheck affected future crew assignments. Changing the qualification fields requires a review against the current requirement; changing only reminder timing does not rewrite the accepted original. Archiving a requirement retains its files and review history.

The older single Legacy recorded document expiry remains separate metadata. It can still constrain an assignment until deliberately changed or cleared on the crew record. It does not create a document, prove coverage or count as a studio review.

Upload and review an exact original

Upload a PDF or a single JPG, PNG or WebP image, up to 8 MB. Record its valid-through date and timezone when needed. The date includes that entire local day. An ambiguous expiry boundary is rejected for review. Files are private, checked against their declared size and SHA-256 checksum, and retained with immutable version metadata.

Uploading a renewal does not replace the accepted version. Open Download this private original, inspect that exact file, choose Accept for studio scheduling, Request a corrected version or Withdraw this version’s acceptance, and record your decision. Confirm the review before saving. Acceptance records a team decision; it does not independently verify insurance, a license or the truth of an uploaded document.

For a worked example, Harper’s accepted original is recorded as valid through October 3. Their October 10 shift needs a renewal. Upload the new October 31 original: the October 3 version remains accepted and the shift stays held. Review the new original and its date. If all other rules pass, the shift moves to reconfirmation and Harper must accept the current assignment again. The old original, earlier decision and prior shift acceptance remain in history.

A stale review cannot overwrite a newer document decision. Reload and review the current version. If an upload’s response is uncertain, use Retry original upload with the retained file and request. The service recovers the same private version and object instead of creating another original. An operator whose access is revoked cannot finalize or replay the operation.

Use the history controls at the bottom of the page to read earlier originals and decisions. Each page contains up to 20 versions per document and 20 decisions per version. The original download link checks current membership and then issues a short-lived private URL. Do not share that URL as a permanent crew portal link. Crew shift links never reveal document originals, private review notes, reminder preferences or the document roster. Referenced originals are protected from generic asset deletion.

Enable and recover expiry reminders

Reminder delivery has two separate controls: enable automatic expiry emails on the document requirement, then confirm the named person’s operational reminder preference and exact current email address. This is separate from marketing. Review the recipient’s actual preference before enabling it.

Choose up to five intervals from 0 to 180 days before the recorded expiry, a local send time and timezone. A worker prepares one immutable reminder for a matching accepted version, review, policy and recipient preference. If several intervals were missed, it chooses the nearest interval already due. A missing or repeated reminder clock time creates a visible hold instead of silently choosing an offset. Update the requirement to an unambiguous time.

Emails contain the document type and recorded expiry, a request to contact the coordinator, and a stop-reminders link. They do not include the original file or a private download URL. Turning reminders off, changing the email, replacing the accepted version, withdrawing its review or losing the authorizing operator’s membership prevents an obsolete queued reminder from being sent.

Delivery remains held until email configuration and the crew-document feature are activated. An unattempted reminder can be reviewed against the configured sender. The confirmation shows its recipient, subject, From and Reply-to addresses. Provider acceptance, confirmed delivery and failure remain separate states. If acceptance is uncertain, recovery keeps the original request identity within a bounded retry window. A changed sending account or expired safe retry window holds the original for reconciliation; it does not silently send another email. A stop-reminders link disables future reminders to the matching address but cannot recall mail already accepted by the provider.

Local development tests use deterministic storage and email simulators. Real private storage, email delivery, signed callback processing and worker activation remain coordinated setup and rehearsal gates.

Integrate with a named account session

The v1 endpoints require a named Clerk account session and X-Workspace-Id. Scoped wb_live API credentials are rejected for these private crew operations. Inspect the current schema at /api/v1/openapi.

Use /api/v1/resources/crew for the directory and mutations, /api/v1/resources/crew/{id} for private details, and /api/v1/resources/crew/{id}/documents for a multipart upload containing metadata as a JSON string and file. The metadata pins the exact filename, MIME type, byte length, SHA-256 checksum in base64, stable request UUID and expected document revision. The body permits the 8 MB file plus a bounded 32 KB multipart envelope. A conflicting revision or reused request with different input returns a conflict.

/api/v1/resources/crew/documents/{versionId} checks current private access before redirecting to a signed original download. Detail responses expose version identities, never a reusable raw storage-object identity. History queries use versionsPage, reviewsPage, noticesPage and appointmentsPage, starting at 1.

Run a crew season

Open Crew scheduling → Season workload & crew pay report to see all assignments in a selected period, scheduled hours, confirmation gaps, estimated cost, recorded earnings and unpaid recorded work. Exports include UTC timestamps and cents; report boundaries are UTC calendar dates. The report covers up to 10,000 assignments and asks for a narrower period if needed.

Recorded pay is an operational ledger. It does not calculate overtime, payroll deductions or taxes. A worked shift can be posted to Expenses once. Its amount uses the stored shift rate and recorded minutes, rounded to integer cents. The expense captures payment status when posted; reconcile later payment changes in Expenses. Posting an expense does not initiate a payout.

Invite someone to their private crew workspace

Open a crew record and create a private workspace link. That link gives the named crew member access to their own upcoming assignments across this business, their enrollment answers and crew agreements. Share it only with them. Anyone holding it can respond and sign. Creating a replacement link revokes the previous link; Revoke access closes it immediately. Links expire after 180 days by default.

Crew members can accept or decline exact assignment revisions and record Ready, On my way, Arrived or I need help within seven days of a currently accepted assignment. An assignment revision invalidates readiness for the previous revision. Readiness notes appear in the private crew record.

The enrollment form collects contact details, roles, emergency contact, meal and access needs, experience and equipment. Submitting does not overwrite the directory. A business operator selects which contact/role fields to apply after review. Removing a role used by an active assignment is blocked until that assignment is resolved. Applying a different email pauses operational reminders so the new address can be reviewed.

Configure assignment and readiness emails

The crew record offers operational triggers for an unanswered offer after a configured delay, a changed assignment needing reconfirmation, an upcoming call, a relative readiness request and an optional fixed local morning check-in on the assignment date. The recipient can turn these emails off in their workspace. This preference is separate from document-renewal and marketing preferences.

The worker uses one durable request identity per shift revision, trigger and recipient policy. It checks current assignment, consent, address, invitation and operator access again before dispatch. Superseded messages do not send. The UI distinguishes queued/failed work from processed work; processed means accepted by the provider or superseded, not confirmed inbox delivery. Signed provider callbacks now retain delivery, bounce and failure receipts independently of outbox processing. They require callback configuration and provider rehearsal during activation. A delivery failure pauses the matching email policy; review the address and preference before re-enabling it.

Delivery requires the coordinated email sender, worker, integration-encryption key and crewOperations feature activation. A link created before encryption setup still works when shared manually; create a replacement after setup to enable its use in reminder emails. No email or SMS is sent by merely publishing these code changes. Operational SMS uses a separate recipient-verified permission and sender activation process described below.

Publish and sign crew terms

Create a season or event agreement with your reviewed text and dates. Save up to 100 reusable agreement templates for the business; applying one prepares the next draft and never changes an already published agreement. Published text, named person, email and scope are frozen and hashed. The crew member reviews the exact document and gives explicit consent when applying their typed or drawn signature. A business operator can countersign it. The saved record includes both names, timestamps, explicit electronic consent, the original document hash and a separate digest of each retained signature mark. Drawn marks do not change the original frozen document hash. Private-link signing records intent; it does not independently verify the signer’s identity.

To change published terms, void the agreement with a reason and publish a new one. Voiding retains the original text and signatures. Crew members can print or save their record from their workspace. This feature does not supply jurisdiction-specific legal terms or certify enforceability.

The named-account API exposes /api/v1/resources/crew/{id}/program for private program reads and mutations, and /api/v1/resources/crew/season for reporting/CSV. The same authorized services handle the web controls. Revision checks and stable request IDs prevent replay from changing an already-applied operation.

Coordinate staffing and operational texts

Open Crew scheduling → Required staffing & coverage. Add a role, time interval, required count and optional exact location. Confirmed coverage includes only current accepted, eligible assignments; offers and stale acceptances do not count. Simultaneous requirements consume separate people. A person cannot satisfy two simultaneous positions, and location-specific needs are allocated before flexible needs. The board identifies the missing person-minutes in each interval and offers eligible candidates through the existing assignment invitation flow. It does not silently book a person or send an invitation.

In a person’s crew workspace, approve the SMS program, timezone, quiet hours and daily cap. The crew member must then explicitly consent and send the displayed one-time WBCREW code from their saved US phone number to the activated sender. A checkbox alone is insufficient. Permission is specific to the current phone, sender and private crew link; replacing that link requires fresh verification. Marketing consent remains separate.

Texts use the same current assignment, readiness and optional local morning timing rules. They include the assignment revision, call time, location, private workspace link and an exact reply code. A READY WK… reply can record readiness only for the current accepted assignment revision. Earlier replies are retained as history rather than acknowledging a newer plan. Ambiguous replies from a phone used in other workflows are left unassigned rather than guessed.

The sender respects quiet hours, a rolling 24-hour per-person cap, current opt-out state and the workspace’s enrolled spending allowance. Delivery shows queued, accepted, delivered, failed and uncertain separately. A timed-out carrier request remains uncertain and is reconciled through signed callbacks; it is not automatically sent again. STOP blocks later dispatches. START alone does not restore operational consent; use a new phone-verification code.

During coordinated setup, activate the US sender, operational consent notice, signed inbound/status URLs, SMS pricing and usage caps, encryption and worker. Rehearse sender changes, duplicate callbacks, opt-out races, old reply codes, provider outages and local morning clock changes before enabling real crew texts.