Workflow steps describe what AlgaPSA should do after a trigger starts a workflow. Some steps perform business actions, such as updating a ticket or sending an email. Other steps control the path of the workflow, such as waiting, branching, looping, or handling errors.

Business action groups

Action group	What it does	MSP example
Ticket	Create, find, update, assign, close, add notes, or add time entries.	Assign urgent GreenLeaf Dental tickets to the escalation team and add an internal note.
Client and contact	Find client or contact records for later steps.	Look up the primary contact before sending an onboarding email.
Communication	Send email or notifications.	Notify dispatch when an appointment is rescheduled.
Scheduling	Assign users or teams to scheduled work.	Route after-hours visits to the on-call technician.
Project	Create or update project tasks.	Create onboarding tasks when a new managed services agreement starts.
Time	Create time entries.	Record standard administrative time for a predefined internal process when appropriate.
CRM	Create activity notes.	Log that an account manager follow-up was created after an invoice became overdue.
Transform	Reformat or normalize data between steps.	Convert event details into a message format used by email or notification actions.
AI	Infer structured information or compose text.	Summarize an inbound message and classify whether it looks like a security incident.
Data Store	Read and write persistent key-value pairs or entity links that survive across workflow runs.	Track how many escalation reminders have been sent this month, or map a monitoring-alert ID to the AlgaPSA ticket that was opened for it.

Fixed values versus mapped values

Most actions need inputs. There are two common ways to provide them:

Input type	Use it when	Example
Fixed value	The value is always the same.	Send to `dispatch@yourmsp.example`.
Mapped value	The value should come from the trigger or an earlier step.	Use the ticket title in the notification subject.

A good workflow usually combines both. For example, an overdue invoice workflow may use a fixed accounts-receivable email address and mapped invoice fields for client name, amount, and due date.

Branches: if this, then that

Use an If branch when the workflow should behave differently based on business rules.

Examples:

If the client is marked VIP, notify the service manager.
If the ticket priority is critical, assign the escalation team.
If an invoice is more than 30 days overdue, notify the account manager instead of sending a normal reminder.
If an appointment is canceled by the client, create a follow-up task.

Branches help keep one workflow flexible without creating separate workflows for every small variation.

Loops: repeat work for a list

Use For Each when the workflow needs to repeat the same step for multiple records.

Examples:

Create onboarding tasks for each standard onboarding checklist item.
Notify each assigned project stakeholder when a milestone changes.
Process each device returned by an asset lookup.

Keep loops focused. If a loop updates many client-facing records, test it carefully before publishing.

Wait steps

Wait steps pause a workflow until a time or event occurs.

Wait type	Use it for	Example
Wait for time	Delay a next step by a duration or until a specific time.	Wait two business days after sending an invoice reminder before alerting the account manager.
Wait for event	Pause until a related event happens.	Wait for payment received after an overdue reminder, then stop further follow-up.

Waits are useful for multi-day processes, but they also make workflows harder to reason about. Document the expected waiting period in the workflow description.

How "Wait for event" resumes

A Wait for event step resumes when an incoming event's payload includes a correlation key matching the entity the step is waiting on. AlgaPSA automatically derives correlation keys from standard payload fields: ticketId, clientId, invoiceId, projectId, and paymentId. If an event arrives but does not carry a field matching the waiting entity, the step continues to wait.

If no matching event arrives before the configured timeout, the step throws a TimeoutError. To handle this gracefully, wrap the event.wait step in a Try/Catch block and define a fallback path — for example, send an escalation alert or continue without the expected confirmation.

When you publish a workflow that contains an event.wait step, AlgaPSA checks whether the chosen event type can be correlated. If the event type has no standard correlation fields, publishing is blocked with an EVENT_WAIT_UNCORRELATABLE error. Choose a different event type or adjust the correlation expression to resolve it.

Try/catch and error handling

Some actions depend on outside systems or required data. A Try/Catch block lets you define what should happen if a step fails.

Examples:

Try to send an email; if it fails, create an internal ticket.
Try to update a project task; if it fails, notify the project manager.
Try to call an integration; if it fails, add an audit note for review.

Use error handling for processes that should never fail silently.

Sub-workflows

A workflow can call another workflow. This is useful when several processes share the same standard task.

Examples:

A standard Notify Service Manager sub-workflow used by ticket, SLA, and security automations.
A standard Create Client Follow-Up Task sub-workflow used by billing and project automations.

Use sub-workflows when the process is stable and reused. Avoid creating sub-workflows too early, before the main workflow is proven.

AI steps

AI steps can help classify, summarize, or compose text. Use them when natural language is part of the process.

Good uses include:

summarizing a long inbound email for an internal ticket note;
classifying whether a ticket sounds like a security incident;
drafting a client-friendly update for manager review;
extracting structured details from an integration alert.

For client-facing AI output, consider adding a human review step before sending.

Data Store: sharing state across workflow runs

The Data Store actions let workflows read and write persistent key-value pairs that survive beyond a single workflow run. Values are scoped by tenant, namespace, and key, and can carry an optional time-to-live (TTL) after which they expire automatically.

Two sub-groups are available:

Sub-group	What it does	MSP example
`store.*` — Key-value store	Get, set, delete, increment, or list values in a named namespace.	Track how many escalation emails have been sent for a client this month; reset the counter at month end.
`links.*` — Entity links	Upsert, look up, delete, or list typed links between two entities; supports forward, reverse, and bidirectional traversal.	Maintain a mapping from a monitoring-alert ID to the AlgaPSA ticket ID that was opened for it, then look it up to avoid creating duplicate tickets.

Permission note: Listing available namespaces (store.list_namespaces) requires the workflow:read permission.

Use Data Store when:

A workflow needs to remember a value and hand it to a different future workflow run (not just the current run).
Multiple workflow types share a piece of state, such as a rate limit counter or a deduplication record.
You need to map external identifiers (monitoring alert IDs, vendor record IDs) to AlgaPSA entity IDs across runs.

Prefer in-workflow data.* storage for values that only matter within the current execution.

Ticket action: additional data fields

Response state

The tickets.find action returns a response_state field on each ticket: awaiting_client, awaiting_internal, or null. Use this field in a branch condition to route a workflow based on who is expected to reply next — for example, skip a follow-up if the ticket is already awaiting a client response.

You can also supply response_state as a filter input to tickets.find to return only tickets that match a specific response state.

Comment ordering and pagination

When including comments in a tickets.find result, three options are available:

Option	Description
`include.comments_order`	`asc` (oldest first, default) or `desc` (newest first).
`include.comments_created_after`	ISO timestamp — return only comments created after this point in time.
`comments_meta` (output)	`{ total_count, returned_count, truncated }` — indicates when the full list was cut short by the result limit.

Use comments_order: desc with comments_created_after to read only recent comments without loading the full history.

Client and contact phone lookup

clients.find

The clients.find action accepts a phone input to locate a client by their location phone number. Control the matching mode with phone_match:

Mode	Use when
`exact` (default)	The full normalized number is known.
`last10`	The caller may have omitted the country code.
`last7`	The area code may also be missing or inconsistent.

The action returns a matched_location object containing the location ID, name, and phone that matched. Inactive locations are excluded.

contacts.find

The contacts.find action supports the same phone_match modes (exact, last10, last7) for phone-based contact lookups.

Navigation

15.4. Workflow Actions and Control Flow

Business action groups

Fixed values versus mapped values

Branches: if this, then that

Loops: repeat work for a list

Wait steps

How "Wait for event" resumes

Try/catch and error handling

Sub-workflows

AI steps

Data Store: sharing state across workflow runs

Ticket action: additional data fields

Response state

Comment ordering and pagination

Client and contact phone lookup

clients.find

contacts.find