Sanka

Action how-to guide

Run record actions, object actions, workflow actions, document actions, email actions, and property migration safely in Sanka.

Last updated: May 28, 2026

Use this guide when you need to run an action from a record, selected records, or a workflow in Sanka. It explains how to choose the right action scope, prepare source data, run conversions and document actions, review results, and give AI enough context to avoid unsafe sends or duplicate records.

What actions do

Actions let you run business operations from Sanka records and workflows. Depending on the object and workspace setup, an action can:
  • Create a downstream record, such as an invoice from an order.
  • Update fields on one or more records.
  • Convert or aggregate records.
  • Issue, download, or email documents.
  • Start an approval step.
  • Import, export, or sync data with a connected service.
Actions change real workspace data, so always confirm the scope, selected records, destination records, required fields, and customer-facing sends before running them.

Choose the right action scope

If you need to...UseWhy
Process one reviewed recordRecord actionYou can check the customer, amount, status, line items, and related records before running.
Process selected records in bulkObject actionYou can run the same operation for a controlled set of records from the object list.
Run automatically after a trigger or scheduleWorkflow actionThe workflow can start after an event, time, or manual trigger and run actions in sequence.
If the action sends email, exports data, syncs an integration, creates financial records, changes inventory, or updates many records, start with a test record or small selection.

Ask AI to review the action first

Before asking AI to run or troubleshoot an action, ask for a dry review. The review should describe the action plan and evidence to check, not perform the operation.
Sample prompt
/sanka Review this Sanka action before it runs. Identify the action scope, source records, destination records, fields copied or updated, required fields, permissions, approvals, customer-facing sends, integration syncs, duplicate risks, and the records or history I should check after it runs. Do not run the action yet.

Run a record action

Use a record action when you are working from one record detail page and want to process that exact record.
  1. Open the source record.
  2. Review the customer, owner, status, amount, line items, related records, and required fields.
  3. Open the action menu.
  4. Choose the action, such as creating an invoice from an order or issuing a document.
  5. Review the action form, copied fields, destination object, and any required values.
  6. Run the action only after the preview or form looks correct.
  7. Open the created or updated record and confirm the association back to the source record.
Expected success state: the destination record exists, required values are correct, the source relationship is preserved when supported, and the action history shows the result.Do not rerun a record action just because the destination record is not visible in the current view. First check filters, archived records, permissions, action history, and workflow history.

Run an object action

Use an object action when the same action should apply to selected records in an object list.
  1. Open the object list.
  2. Filter the list so only the intended records are visible.
  3. Select the records to process.
  4. Confirm the selected count and exclude already-processed records.
  5. Open the action menu and choose the action.
  6. Review the form, destination, templates, recipients, and timing.
  7. Run a small test batch before using a large selection.
  8. Review action history to see which records succeeded, failed, or were skipped.
Expected success state: every valid selected record is processed once, failed records show a reason, and any created records, files, messages, or sync results can be reviewed.If only part of a batch succeeds, do not rerun the full original selection. Filter to the failed or unprocessed records first.

Use property migration in conversions

Property migration copies selected field values from a source record to a destination record during a conversion or creation action. Use it when teams need shared identifiers, customer context, delivery details, or management numbers to continue across objects.Example: a project management number should move from Deal to Estimate, then from Estimate to Order.
  1. Create or confirm the source and destination properties.
  2. Use compatible property types when possible.
  3. Make the property required only when every source record can provide the value.
  4. In the conversion action, map the source property to the destination property.
  5. Run the action on a test record.
  6. Confirm the destination record shows the copied value and the source association.
Property migration does not fix blank or incompatible source values. If a field is empty, invalid, or not mapped, the destination record may be created without that value or the action may fail validation.

Issue documents

Document actions create files from record data and a selected template.
  1. Confirm the source record has the customer, line items, dates, totals, and related records needed by the template.
  2. Choose the document action from the record or object list.
  3. Select the template.
  4. Preview when available.
  5. Run the action.
  6. Open the action result, downloaded file, or record attachment.
  7. Confirm the file uses the expected customer, amount, date, and template.
If a document looks wrong, check the source record and template fields before changing product code. Most document problems come from missing record values, the wrong template, or an outdated template field.

Send documents by email

Email actions can send customer-facing messages. Treat them as sensitive operations.
  1. Confirm the recipient email address on the contact, company, or related customer record.
  2. Confirm the sender, subject, body, template, attachment, and send timing.
  3. Use a test record or draft when available.
  4. Review the final message before sending.
  5. Run the send action.
  6. Check message history and action history before retrying.
Do not rerun an email action until you know whether the first attempt sent, failed, or is still pending.

Configure message templates

Message templates help standardize document emails and repeated customer messages.
  1. Open the message or template settings area for the workspace.
  2. Create a template with a clear name.
  3. Add the subject and body.
  4. Insert placeholders only for fields that reliably exist on the related records.
  5. Test the template with a record that has realistic customer and document data.
  6. Review the rendered message before using it for bulk sends.

Review action results

After an action runs, check the result before replying to a customer or running it again.
Search Sanka...
Action result checkpoints

Logs

Search logsAll actionsAll dates
ID / ActionDateTarget / ItemChangeActor
1Action scope reviewedMay 23, 2026Order listSelected 3 confirmed orders and excluded already-invoiced ordersOperations user
2Object action completedMay 23, 2026Create invoices action2 invoices created and 1 record skipped because a required billing date was missingSanka action
3Result checkedMay 23, 2026Invoice recordsVerified customer, amount, due date, source order association, and action historyOperations lead

For actions that create records, send email, issue documents, update inventory, or sync integrations, review both the source record and downstream result before deciding whether the behavior is expected or a bug.

Check:
  • Source records and selected record count.
  • Destination records, files, messages, exports, or sync results.
  • Required fields, copied fields, and associations.
  • Action history and workflow history.
  • Customer-facing sends before retrying.
  • Failed or skipped records before rerunning a batch.

Troubleshoot common issues

IssueWhat to check
The action is not visibleConfirm the object, selected record scope, permissions, module availability, templates, and whether the action is supported for that record type.
A required field error appearsCheck whether the source record has the required customer, item, date, amount, location, email address, template, or mapped property.
The created record is missingCheck action history, destination object filters, archived records, permissions, and whether the action failed validation.
Duplicate records were createdCheck whether the action was run more than once, whether selected records already had downstream records, and whether workflow conditions prevent duplicate runs.
A document is wrongCheck the source record values, template, template fields, and whether the correct record was selected.
An email did not sendCheck recipient address, sender settings, template, attachment, send timing, message history, and action result.
A workflow action did not runCheck whether the workflow is enabled, the trigger fired, conditions matched, approvals completed, and required fields existed at run time.
AI wants to change code immediatelyAsk AI to compare expected behavior, action history, record data, permissions, templates, and integration state before proposing a code change.

AI-safe support prompt

Use this prompt when a customer reports an action issue.
Sample prompt
/sanka Triage this Sanka action issue before replying or proposing a code change. Classify it as record action, object action, or workflow action. Check the source records, selected count, destination records, required fields, copied fields, associations, permissions, templates, message history, workflow history, action history, and whether any customer-facing send or integration sync already happened. Summarize expected behavior, missing evidence, safe next checks, and whether this looks like configuration, data, permission, or product behavior. Do not rerun the action, send messages, change records, or propose a code change until the evidence is reviewed.