Publishing work for tenant admins

This guide tells tenant admins how to craft integrations, ProcessFlows, and WebApps so Operations My Work shows honest, actionable work. Use the Tenant Admin Console you already have — ProcessFlow editor, integrations, WebApps, DataPool. Do not invent a second task system.

Goals

1. Employees only see human-valuable work (approvals, actions, exceptions).
2. Approve/Reject appears only when a real process human-input gate is open.
3. My Work stays empty until real processes write rows — never seed demo employee tasks.

Checklist

1. Prepare the request model — On Operations /, use Prepare request model (installs DataPool schema operational_requests). Or call POST /api/v1/operations/request-model.
2. Connect source systems — Create integrations for CRM / ERP / support (Tenant Admin → Integrations). Test connectors before process wiring.
3. Publish business ProcessFlows — Set process category to business so operators see runs under /runs.
4. Write My Work with helpers — Prefer tf.operations.openApproval / openAction / openException / updateProgress / complete (requires sandbox api capability).
5. Validate — tf.operations.validate(payload) or POST /api/v1/operations/requests/validate before go-live.
6. Wire human input for approvals — Pause the process, capture the pending human-input id, pass it as human_request_id in the same step that opens approval (or the next step immediately after).
7. Optional WebApp intake — A WebApp may start the process; it should not invent My Work rows itself. The process owns upserts.

Work kinds to publish

Enrich employee clarity with why_visible, consequence, and ai_summary.

Approval example

// After the process creates a pending human decision:
const pendingId = String(human_request_id ?? "");
await tf.operations.openApproval({
  external_id: `crm-${account_id}`,
  subject: "Approve customer credit limit",
  party: account_name,
  process_name: "Customer credit review",
  human_request_id: pendingId,
  why_visible: "You are the credit owner for this account.",
  consequence: "Approving raises the credit limit in CRM.",
  required_action: "Confirm risk checks and approve or reject.",
  journey_beat: "in_process",
  journey_stage_label: "Credit decision",
  checks: [
    { label: "KYC complete", state: "verified" },
    { label: "Risk score", state: "needs_review" }
  ],
  system_refs: [{ system: "CRM", label: "Account", external_ref: account_id }]
});

If human_request_id is missing, openApproval throws. A raw api.put with attention: "approval" and no id soft-warns; pass strict: true to reject.

Integrations

• Use connectors to read case/order/ticket state and write outcomes after Approve/Reject.
• Map stable external_id values from the source system so upserts update the same My Work card.
• Keep employee-facing copy in process fields (required_action, why_visible), not raw connector error payloads.

ProcessFlows

• Automatic steps: call connectors / DataPool; use updateProgress so the journey strip advances.
• AI-assisted steps: put a short result in ai_summary; still require a human gate for decisions.
• Human steps: open approval or action; set actor_hint: "person".
• Failure paths: openException with clear recovery text; store input so Retry works when appropriate.

WebApps

• Forms and portals start or continue processes; they are not a parallel My Work writer.
• After a WebApp POST executes a process, that process should open the correct work kind.
• See WebApps ProcessFlow integration.

Common failures

Related

• Operational requests and My Work
• Template: customer onboarding
• Process sandbox tf API