RivetOps Book a demo

Docs

Implementation notes for admins and developers.

Set up teams, import workers, connect work orders, and send operational events into RivetOps.

Quickstart

Start by modeling one operating territory. Add the teams that dispatch actually manages, import workers with stable employee IDs, create territories, then connect or upload the current work order queue.

  1. Create the organization and default territory.
  2. Invite dispatchers, supervisors, integration admins, and read-only stakeholders.
  3. Import workers with role, home base, manager, territory, and certification fields.
  4. Connect a work order source or upload a CSV extract for pilot validation.
  5. Define closeout requirements for the work types included in launch scope.

Workspace model

A workspace contains the operating rules for one company. Teams, territories, worker records, work order sources, dispatch rules, closeout templates, notification routes, and reporting exports all live inside the workspace.

Territory

A service area, branch, region, or route group used for coverage planning.

Worker

A technician, crew member, contractor, or field employee who can be assigned work.

Work order

A source-system job with priority, site, asset, window, required skill, and status.

Exception

A customer-impacting risk or blocker with owner, next action, and status.

Imports

Imports require stable external IDs. RivetOps can reconcile updated worker and work order records when source systems send repeat records with the same IDs.

Worker employee_id, name, role, territory, manager, home_base, certifications, availability_windows
Work order external_id, site, asset, priority, customer_window_start, customer_window_end, required_skill, status
Closeout work_type, required_photos, required_readings, required_signature, checklist_template, billing_hold

API request

Create or update work orders through the REST API. Use stable external IDs so RivetOps can reconcile updates from field service, CRM, or ticketing systems.

POST /v1/work-orders
Authorization: Bearer <api_token>
Content-Type: application/json

{
  "external_id": "<work_order_id>",
  "site": "<service_site>",
  "priority": "urgent",
  "required_certifications": ["required_certification"]
}

Webhooks

Subscribe to operating events when downstream systems need current status. Webhook payloads include workspace ID, source ID, event type, occurred time, affected object, and a stable external reference.

assignment.created escalation.opened shift.coverage_risk closeout.evidence_missing work_order.closed

Permissions

Roles are designed around operating responsibility. Admins configure the workspace, dispatchers assign work, supervisors own exceptions, technicians complete mobile closeout, finance reviewers clear billing holds, and integration admins manage source systems.

Mobile closeout

Closeout templates define what a technician must provide before work can move to review. Requirements can vary by work type, customer, territory, asset class, or compliance rule.

Photos

Minimum counts, labels, and required views.

Readings

Meter, pressure, temperature, usage, or inspection values.

Checklists

Safety, access, repair, inspection, and customer confirmation steps.

Approvals

Supervisor, finance, compliance, or customer signature holds.

Launch checklist

Before launch, confirm source mappings, roster accuracy, dispatch ownership, notification routes, mobile login, export format, support escalation, and the first territory's success criteria.