Skip to main content

​
How to use these recipes

Each recipe is a design pattern, not a workflow to enable unchanged. Adapt the table, status names, owners, form versions, action names, and permission scopes to your organization. Build it in an approved non-production workspace first, verify every output, then move through a controlled rollout. Every recipe follows the same safe shape:

​
Recipe 1: route a service request to the right case queue

Use when: A public-service request must become an accountable internal case without creating duplicates.

​
Build it step by step

  1. Test the intake event with a non-production request such as REQUEST-TEST-001.
  2. Inspect the trigger output and identify the exact source ID and category fields.
  3. Find existing open cases for that source ID.
  4. If one exists, stop or update the existing case according to the service policy.
  5. If none exists, create a single case with a clear source relationship and a queue-owned status.
  6. Create a task only after the case is created successfully, so the task always has a reviewable target.
  7. Notify only the queue owner or a constrained member selector—not a broad organization-wide audience.
Common extension: Add a category-to-unit lookup after the duplicate check. Keep the fallback explicit: if no unit is found, create a review task for a central triage team instead of guessing the owner.

​
Recipe 2: prepare and track a field inspection

Use when: A case must be scheduled or prepared for a field team after an eligibility decision.

​
Why the status transition matters

Do not trigger on every update to an application. An address correction, attachment upload, or note change should not schedule another inspection. Require the expected old/new state or an equivalent explicit eligibility marker, and record which inspection case was created.

​
Test cases to run

  • Eligible application with no prior inspection: creates exactly one inspection case and task.
  • Eligible application with an existing open inspection: creates no duplicate; updates or flags the existing case according to policy.
  • Incomplete address: creates no inspection; creates a review task only if that is the approved exception path.
  • Unrelated update: produces no action.

​
Recipe 3: escalate an aging service case

Use when: A case needs attention after a defined service-level threshold, while avoiding repeated alerts.

​
Make the escalation useful

An escalation should carry the information needed to act: source case ID, current queue, age, responsible unit, next expected decision, and link or relationship to the case. Avoid sending a generic alert that requires the recipient to search for context.

​
Recipe 4: produce a decision document after approval

Use when: An approved form or decision must create a controlled document that can be attached to the case.

​
Document controls

Treat the template as part of the service policy. Test it with empty optional values, long text, Arabic content, and each allowed decision outcome. Verify that the generated artifact has the right headings, signatory information, date, and attachments before using it in a live process.

​
Recipe 5: provide a controlled dashboard or form response

Use when: A dashboard widget or form must receive calculated data without exposing records outside the user’s permitted scope.

​
Response design checklist

  • Define the JSON fields, types, and empty-state behavior before building.
  • Return identifiers and summaries only when the interface needs them.
  • Do not return private notes, internal-only fields, or broad record lists merely because the automation can query them.
  • Test malformed input, zero matching records, multiple matching records, and a request outside the intended scope.

​
Recipe 6: close the loop after a reviewed task action

Use when: An accountable role completes a task action and the source case needs a consistent follow-up.
  1. Start with On Task Action for the exact task type.
  2. Narrow it to the approved old/new status transition where available.
  3. Read the source case through the task’s stored relationship or known ID.
  4. Confirm that the task action is the expected approved outcome.
  5. Update the source case with the decision and next status.
  6. If policy requires a new hand-off, create the next task or notification only after the case update succeeds.
  7. Keep the completed task, case, and any generated document linked so the decision trail can be reviewed.

​
Rollout checklist for every recipe

  1. Build with an approved non-production record and non-production recipients only.
  2. Verify the trigger payload, condition, every read, every write, and final result.
  3. Run each negative case: missing data, unrelated update, duplicate attempt, wrong status, and unauthorized scope.
  4. Have the service owner review the created record, task, document, or response—not just the automation editor output.
  5. Enable the smallest service scope first.
  6. Monitor the first live results and retain a clear path to disable the flow if results differ from the approved design.
Never copy a recipe directly into a live service. Each one requires the organization’s own data model, access rules, approval boundaries, and accountable owner.
KayanOS Automations recipe for a controlled service escalation.

​
Continue building