Sanka

Workflow overview

Understand workflow basics, trigger types, action steps, expected behavior, troubleshooting, and safe AI checkpoints.

Last updated: May 29, 2026

Workflows automate operations in Sanka. For example, you can configure workflows to allocate inventory when an order is created, notify a team member when stock is low, or create an invoice after approval. A workflow combines a trigger with one or more actions. The workflow gallery includes reusable templates that you can copy into your workspace. Before enabling a workflow that changes records, sends messages, exports data, or syncs with an integration, review the trigger, conditions, actions, and expected result.
Sample prompt
/sanka Review this Sanka workflow before I enable or run it. Summarize the trigger, target object, conditions, actions, records that may be created or updated, approval steps, customer-facing sends, integration syncs, duplicate-run risks, and the history or records I should check after it runs. Do not enable or run the workflow yet.

Workflow object

Create and edit workflows from the workflow object. Use the new button to create a workflow. Workflow object list On the workflow creation screen, set the title, owner, trigger, conditions, and actions. Workflow creation screen

What is a trigger?

A trigger starts a workflow run. Choose based on how you want the workflow to begin.
TypeBest forExample
Event triggerReacting to record creation or updatesAllocate inventory when an order status becomes confirmed
Time triggerRunning on a scheduleNotify about open tasks every morning at 9:00
Manual triggerRunning only when neededRun a month-end batch once
The setup flow is usually the same: create a workflow, choose a trigger, add conditions if needed, add actions, then enable the workflow.

Event trigger

Use an event trigger when a workflow should run after a record is created or updated.

Common uses

  • Allocate inventory after an order is confirmed
  • Create an invoice after approval
  • Notify an owner when a record changes
  • Apply the same rule automatically to reduce manual mistakes

Setup tips

  1. Select the event trigger type and choose the target object.
  2. Choose which change should start the workflow, such as create or update.
  3. Add specific conditions to reduce unnecessary runs, such as only when status is confirmed.

Time trigger

Use a time trigger to run a workflow daily, weekly, monthly, or on another schedule.

Common uses

  • Closing work
  • Regular notifications
  • Finding records close to their due date
  • Batch processing that should run at regular intervals

Setup tips

  • After choosing the schedule, confirm the workspace time zone.
  • If many records are involved, filter the target records to reduce load and duplicate work.

Manual trigger

Use a manual trigger when a user should decide exactly when the workflow runs.

Common uses

  • Month-end batch work
  • One-off operations
  • Initial verification after setup
  • Work where a person should decide the timing

Setup tips

  • Define who is allowed to run the workflow to prevent unintended execution.
  • Test with a small amount of data before using it broadly.

Action types

Actions are the operations that run after the trigger. Common action types include:
  • Approval action
  • Create object record
  • Update object record
  • Aggregate object records
  • Import data from integrations
  • Export data to integrations
  • Sync data with integrations
  • AI actions and utilities

Operational tips

  • Start with strict conditions and expand after verifying the result.
  • For operations that must not run twice, use conditions or status updates to design a run-once flow.
  • After a workflow runs, review the workflow history and affected records.
  • Keep sending, deletion, export, and integration-sync steps behind approval or narrow conditions until the workflow has been tested.
  • If the workflow creates downstream records, decide how the source record should show that the downstream step is complete.
  • When using AI to help design workflows, ask for the expected success state and failure handling before enabling the workflow.

Expected behavior

When a workflow runs successfully:
  • The workflow starts only when its trigger fires and its conditions match
  • Each action runs in the configured order
  • Approval steps pause the workflow until an approver responds
  • Created or updated records appear in the target object unless they are archived or filtered out
  • Notifications, emails, documents, exports, or integration syncs are recorded in the relevant history or result view
  • The workflow history shows whether the run completed, stopped, failed, or is waiting for approval
A workflow does not run just because a matching record exists. It must be enabled and the trigger event, schedule, or manual run must occur. A workflow also does not bypass required fields, permissions, module availability, or action-specific validation.

Troubleshooting

The workflow did not run

Check whether the workflow is enabled, whether the trigger event or schedule occurred, whether the workspace time zone is correct, and whether the record matched the conditions at the time of the trigger.

The workflow ran too many times

Review the trigger and conditions. For update-based workflows, make sure the workflow does not update a field that immediately satisfies the same trigger again. Add a status, flag, or condition to mark records that have already been processed.

A downstream record was not created

Check the action result, required fields, object permissions, related records, templates, and whether a previous step stopped the workflow. If the action depends on a customer, item, location, approval, or mapping, confirm it existed when the workflow ran.

The workflow is waiting for approval

Confirm the approver, approval status, required approval fields, and notification settings. If multiple approvers are configured, check whether the workflow requires all approvers or only one approver before continuing.

A customer-facing email or document was sent unexpectedly

Check the action history and message history before rerunning or editing the workflow. Then review recipient fields, templates, send timing, and the conditions that allowed the action to run.

AI cannot tell whether this is a bug

Ask AI to compare the trigger, conditions, workflow history, action history, and affected records. Treat it as a possible bug only after confirming the workflow was enabled, the trigger occurred, the record matched conditions, required fields were present, and the user had the needed permissions.

Checkpoints

Use workflow history, action history, record history, and audit logs to confirm exactly what ran and what changed.
Search Sanka...
Review workflow run

Logs

Search logsAll actionsAll dates
ID / ActionDateTarget / ItemChangeActor
3Reviewed workflow setup2026/05/10 09:00Order fulfillment workflowChecked trigger, conditions, and downstream actionsClaude integration
2Workflow run completed2026/05/10 09:15Green Salon Group orderCreated inventory transaction and task after order confirmationSanka workflow
1Checked downstream records2026/05/10 09:22Inventory transactionVerified item, quantity, location, and source order associationSanka user

Workflow review should include the trigger record, each action result, any approval step, and the downstream records created or updated by the workflow.