Sending and Reviewing Contractor Job Packs

Decide how the contractor will receive the pack

Use an email grant when the recipient will open a controlled contractor portal link.

Use a native app grant when the recipient already has a Deucalion app account but is not part of the sending organization.

The sending organization keeps ownership of the work order either way. The contractor does not become an organization member just because they receive a job pack.

Create or identify the contractor

Contractor records are organization-scoped and can be linked to:

1. Contractor name and email.
2. Optional phone and company.
3. Optional CRM contact.
4. Optional native app user.

When both email and app user are supplied, the email must match the app user identity. This prevents accidentally binding a job pack to the wrong native account.

Create a work-order grant

1. Create the grant against the contractor and work order.
2. Choose the delivery identity: invited email, recipient app user, or both.
3. Choose permission.
4. Set expiry by date or days.
5. Deliver the generated access URL for portal use, or let the native push notification point the app user to the pack.

Grant permissions are:

An active native grant must be unique for a work order and recipient user. If the same app user needs a new grant for the same work order, revoke the old active grant first.

What the contractor can see

The job pack is built from the work order and safe related data:

1. Work-order number, status, priority, description, schedule, and items.
2. Site name, address, access notes, scheduling rules, and location fields needed for delivery.
3. Work-order documents that are safe for contractor visibility.
4. Paged site assets for the work area.
5. Contractor and grant metadata needed to display the pack.

The pack does not expose raw access tokens, internal admin notes, unrelated customer workspace records, or data from another organization.

Native app workflow

1. The app user receives a push notification when a native grant is created.
2. The pack appears in External Job Packs.
3. The contractor opens the pack detail from the inbox or deep link.
4. The app loads the grant, job pack, and the user's previous submissions.
5. The contractor submits updates only when the grant permission is submit_evidence.

Native job packs are matched to recipientUserId, not organization membership. This is the important distinction for contractors who already use Deucalion with another organization.

Portal workflow

1. The contractor opens the grant access URL.
2. The portal validates the token, expiry, revocation state, contractor activity, and work-order scope.
3. The portal records view activity.
4. The contractor can submit updates only when the grant permission is submit_evidence.

Contractor portal responses use no-store and noindex headers. Treat the URL as sensitive and revoke it if it was sent to the wrong person.

Review contractor submissions

1. Open Contractors.
2. Filter the submission queue by submitted, accepted, rejected, draft, or all.
3. Select a submission.
4. Review contractor, work order, proposed status, summary, media count, work-item updates, and checklist count.
5. Add a review note.
6. Select Approve and merge, Request changes, or Reject.

Approving a submission merges accepted updates into the official work-order record. Requesting changes and rejecting do not mutate the official work order.

Revoke or resend access

1. Revoke a grant when the contractor should no longer see the pack.
2. Resend a native notification only for active, unexpired, native-bound grants.
3. Review grant events when access is disputed.

Events record creation, sent notifications, views, expiry, revocation, denied access, native binding, and submissions.

Troubleshooting

Reference surfaces

1. Use Contractors for the admin submission queue and contractor APIs.
2. Use Work Orders for the official work-order record after merge.
3. Use the Admin-to-Engineer Handoff Map for the difference between internal engineers and external contractors.