Skip to main content

Workflow Actions vs. Single API Call Actions

MSPintegrations provides two distinct types of actions for working with PSA platforms like Autotask, ConnectWise Manage, and Halo PSA: workflow actions and single API call actions. Understanding the difference helps you choose the right action for your use case.


Single API Call Actions

A single API call action makes one direct request to the PSA API and returns the result. You provide all the parameters yourself, and the action passes them through to the API without adding any additional lookup or decision logic.

When to Use a Single API Call Action

Use a single API call action when:

  • You already know all the required parameters for the object you want to create, update, query, or delete
  • You have already looked up the account, contact, ticket, or other referenced objects in earlier actions and have their IDs available
  • You need precise control over exactly which fields are set
  • You are building a custom multi-step workflow and want to combine individual operations in a specific order

Example

You want to create an Autotask ticket and already know the Account ID and Contact ID from a previous query step. Use API: Create an Object with the Ticket entity, passing those IDs directly.

Single API Call Actions by Platform

Autotask:

ConnectWise Manage:

Halo PSA:


Workflow Actions

A workflow action combines multiple API calls and MSPintegrations business logic into a single step. Rather than requiring you to know every ID and parameter up front, a workflow action accepts higher-level inputs and determines the correct API calls to make on your behalf.

When to Use a Workflow Action

Use a workflow action when:

  • You are processing incoming emails and need the system to determine which account, contact, or ticket the email is associated with
  • You want to look up an account or contact automatically based on the sender's email address or domain
  • You want to find an existing ticket by scanning the email subject or body for a ticket number
  • You need the system to handle edge cases like missing contacts, unrecognized senders, merged tickets, or reply threads

How Workflow Actions Work

A workflow action takes inputs you provide (such as an email address or a ticket subject) and uses MSPintegrations business logic to:

  1. Query the PSA for matching records (contacts, accounts, tickets, configuration items, etc.)
  2. Apply matching rules and handle ambiguous or missing results
  3. Make the appropriate API call (or series of calls) based on what was found
  4. Return the results including status flags and the created or updated objects

For example, the Create Autotask Ticket workflow action:

  • Searches for a Contact matching the sender's email address
  • If no Contact is found, searches for an Account matching the sender's domain
  • Handles unmatched senders (assigns to a default account or creates a new one)
  • Optionally creates a new Contact
  • Creates the ticket with all the correct associations

This replaces approximately 10 separate API calls and the conditional logic between them.

Workflow Actions by Platform

Autotask (Common):

Autotask (Advanced):

ConnectWise Manage:

Halo PSA:


Comparison Summary

Single API Call ActionWorkflow Action
Who determines the API call?You provide all parameters directlyMSPintegrations determines the call based on your inputs
What input is needed?Exact IDs and field valuesHigher-level inputs (email address, ticket number, etc.)
Lookup logic included?NoYes
Best forCustom workflows with known dataEmail-to-ticket automation
Number of API calls madeOneMultiple (handled automatically)
ExampleCreate a ticket with a known AccountIDCreate a ticket by looking up the sender's account

Choosing the Right Action

Start with workflow actions if you are setting up standard email-to-PSA automations. They handle the complexity of contact and account matching automatically.

Use single API call actions when:

  • You have already resolved all the required IDs (from a previous query step)
  • You need to create or update entity types not covered by workflow actions
  • You are building custom logic and need precise control over each step