Automated tasks

Automated tasks let your product logic raise a task for a human to action in response to something that happens on the platform — for example, flagging a policy for manual review when it breaches an SLA, or opening a follow-up task when a claim is approved.

Automated tasks always have the type automated, and are created from product module code — either directly through the Root SDK, or by returning a create_task action from a lifecycle hook.

📘

Availability

Like the rest of task management, automated tasks require the task_management feature flag. If the flag is not enabled, create_task calls are skipped with a warning rather than raising a task.

Creating a task from the SDK

Within product module code you can create a task directly using client.tasks.createTask:

await client.tasks.createTask({
  type: 'automated',
  name: 'Review flagged policy',
  description: 'Policy exceeded its underwriting SLA and needs manual review.',
  priority: 'high',
  referenceType: 'policy',
  referenceId: policy.policyId,
  triggerKey: 'underwriting.sla_breached',
  dedupeKey: `underwriting.sla_breached:${policy.policyId}`,
});

Supported parameters:

Using the create_task lifecycle-hook action

Lifecycle hooks can return a create_task action, which the platform executes on your behalf. This is the simplest way to raise a task from an event in a policy or claim's lifecycle. The action always creates a task of type automated, and defaults referenceType to policy. If you set referenceType to claim, a claim must be in scope for the hook.

📘

Reference types for automated tasks

Automated task creation currently supports linking to a policy (the default) or a claim. Other reference types are available for manually created tasks.

Avoiding duplicates with triggerKey and dedupeKey

Automations often re-run — a scheduled function might evaluate the same policy every night. To prevent a fresh task being raised on every run, use the two idempotency fields:

• triggerKey identifies which automation raised the task (for example underwriting.sla_breached). It is useful for grouping and reporting.
• dedupeKey is an idempotency key. While an open task with the same dedupeKey already exists for the organisation and environment, createTask does nothing and returns the existing task.

Because the dedupe key is cleared once a task reaches a terminal status (done or cancelled), a recurring trigger raises exactly one open task at a time: it won't pile up duplicates while the task is still open, but it can raise a new one after the previous task has been resolved.

A good pattern is to build the dedupeKey from the trigger and the entity it concerns:

dedupeKey: `underwriting.sla_breached:${policy.policyId}`