Workflows
Workflows keep repeated work in a clear order: who starts the process, which steps run automatically, where a person must act, and how a manager sees progress. Use them for sales, customer handoff, request processing, internal procedures, and task chains that should not depend on memory.
A workflow does not replace a task, CRM record, or document. It connects them into a controlled sequence with a visible template, run, current tasks, history, and result.
Where to Find It
The main entry point is Automation → Workflows (/automation/workflows). A workflow can be scoped to CRM or tasks. Older task and CRM links open the same workflow center with the relevant module context already selected.
Depending on permissions, the section includes templates, filters by module, scope, trigger, activity, and object type, template editing, workflow tasks assigned to people, workflow instances, execution history, and planned-step processing. The filters are context-dependent: module and entity type are available in the general Automation center, while some CRM scope filters are hidden in the Tasks context.
If a section or action is unavailable, check workflow permissions and the scope where the process runs.
Main screens:
/automation/workflows- templates, CRM or task context, quick run, and instance preview;/automation/workflows/tasks- manual workflow task queue;/automation/workflows/templates/:templateId/editor- template editor for trigger, audience, and steps;/automation/workflows/instances/:instanceId- one workflow run with history, timeline, and termination.
In the template list, check both the Trigger (when the workflow starts) and the Scope (which pipeline, stage, or task context it covers). Do not treat Last run as the only proof that a workflow works: a blank value can mean it has never run, so confirm the history of the specific instance.
When to Use Workflows
Use a workflow when several steps must stay standardized: handling a new request or opportunity, handing work between teams, creating a task from an event, waiting for a status or deadline, assigning a manual step, or seeing exactly where the process stopped.
If you only need a repeated checklist inside one task, use a task template. If you only need rules for one CRM stage, CRM automation may be enough. Use a workflow when the whole chain and its visibility matter.
Templates
A template defines when the workflow starts and what it does. In the editor, first choose whether it works with a CRM opportunity or a task. Then set the scope: company, pipeline, stage, or the task context.
Before enabling it, check the name, purpose, module, scope, trigger, audience, execution actor, manual assignees, automatic actions, completion rule, and owner.
Do not enable a template if nobody owns errors, overdue steps, or exceptions. Every workflow needs a business owner who can explain the rule to the team.
Editor and Checks
Use the editor as a map of the process. The start node shows the launch event; other steps describe automatic actions, waits, and manual tasks. The connections should read as a clear business order.
Before saving and running a new workflow:
- run validation to see node and connection errors;
- simulate the workflow on a safe test object;
- review the execution preview before creating tasks, notifications, messages, or CRM changes;
- confirm that the audience is not empty or too broad;
- check that a system or integration actor does not grant more power than intended.
Do not test workflows on a real client, active opportunity, or task with private files. For docs and training, use demo objects with clear demo names.
Process nodes and connections
A process is assembled from nodes of different types, joined by connections:
- start - the process entry point;
- action - an automatic step (changing an object, creating a task, notifying);
- condition - a branch based on a rule;
- wait - a pause until a time or event;
- task - a manual step addressed to a person;
- event - a reaction to an external event;
- loop - repeating part of the process;
- parallel - simultaneous branches;
- variables - data passed between steps;
- completion - not a palette node: a branch completes when it has no next step, and the instance moves to a terminal state.
Connections between nodes are labeled so the transition logic is readable: success, else, loop, done. Labels matter most on a condition node and on loops - they show where the process goes depending on the step outcome.
Actions inside an action node
The catalog depends on the module, capability schema, and your permissions. Besides notifications, task creation, and stage changes, it may offer activity or opportunity creation, setting or incrementing a field, starting another workflow, binding task context, sending an external message, and creating or ensuring a client project. For task workflows, bindTaskContext links the process to a project or company; for CRM, project actions belong to the opportunity. If an action is missing, check scope and permission before replacing it with ad-hoc manual tasks.
Workflow Tasks
A workflow task is a manual step assigned to a person. The queue is available in a separate workflow view. Treat each item like real work: read the description, deadline, linked object, workflow instance, and expected result.
Complete the step only after the work is done. If it cannot be done, cancel it or return it to the workflow owner with context instead of closing it formally.
Managers should review the workflow-task queue regularly: stuck manual steps show where automation has stopped waiting for a person.
When reviewing the queue, check the assignee, linked object, deadline, cancellation comment, and repeated tasks that may point to a bad trigger.
Instances and Control
An instance is one run of a template for a concrete opportunity, task, or other work object. Use it to see whether the workflow started, which step is active, who must act, why it finished or was terminated, and whether the template creates unnecessary work.
Terminate an instance only with a clear reason so later review can distinguish a correct manual stop from a setup issue.
If an instance is terminated manually, the reason should make clear whether it was a valid management decision, bad input data, or a temporary pause. Do not use termination to hide a broken template.
Roles and Responsibility
Separate workflow responsibilities: viewing templates and runs, creating and editing templates, manual runs, handling manual tasks, terminating instances, and using system or integration actors.
The assignee of a manual step should not automatically be able to change the template. The workflow owner should see stopped instances and own rule changes.
Errors and Exceptions
Workflow errors usually come from permissions, the wrong scope, a missing participant, the wrong trigger, or an outdated template. Do not work around them with chaotic manual tasks. First record which process, object, and step stopped.
If the problem recurs, check the template's scope, trigger conditions, assignees, task and CRM actions, and the rights of the role that executes it.
Pay extra attention to workflows that send messages, create documents, run AI scenarios, or create tasks. Those actions are visible to other people, so wrong text, recipients, files, or assignees become operational issues quickly.
Train the Team on Demo Workflows
Train employees and test new ideas on demo workflows, not on live clients and real work tasks:
- Create a test template with a clear name and safe data.
- Use demo clients, tasks, amounts, and deadlines.
- Do not include real contracts, contacts, or private links in training materials.
This way a mistake in a workflow condition or action stays a training exercise instead of an email to a real customer.
Good Practice
- Keep one workflow focused on one business goal.
- Name manual steps so the assignee understands the expected result.
- Test new workflows on safe demo scenarios first.
- Run validation, simulation, and execution preview before enabling a template.
- Do not automate a management decision that requires a person.
- Review workflow tasks and stopped instances regularly.
- Change a template only after the team understands the new order of work.
Related Scenarios