Skip to main content

Core Concepts

An automation is the work you configure to happen automatically. Email Processing, Scheduled Tasks, Forms, and PSA Workflows start that work from different triggers. Developer Toolkit and AI Toolkit add capabilities to your action steps; they do not add separate trigger types.

Your User, Organization, and Subscription​

Your user login lets you sign in. An organization is where your team shares automation and resources. You can belong to multiple organizations and switch between them using the same sign-in.

Each organization has one subscription and its own billing account. The subscription determines which modules, actions, and third-party connection types the organization can use, along with any usage limits. Switching organizations changes which subscription and limits apply; access does not carry over from another organization.

  • A module is a major application component, such as Email Processing or AI Toolkit.
  • An action is an operation you add to automation, such as creating a ticket.
  • A connection type identifies a third-party integration, such as Autotask. A connection connects your organization to a particular third-party system or instance.
  • A limit specifies how much your organization can use. For PSA access, the limit typically allows connecting to one instance.

For example: Your subscription includes Autotask access, with a limit of connecting to one Autotask instance.

The Processing Model​

Every run in MSPintegrations follows the same shape:

Trigger
  └── Automation (email rules, a task, a form, or a PSA event subscription)
        └── Action Step(s)
              └── Variables and History

Trigger​

A trigger starts a run: one occurrence of your automation processing its triggering data. Four modules provide triggers:

ModuleTrigger
Email ProcessingAn inbound email arrives at a hosted mailbox, or is pulled from a remote mailbox
Scheduled TasksA schedule tick fires based on a cron-style cadence
FormsA visitor submits a public form
PSA WorkflowsA PSA event (ticket change, asset change, and so on) is delivered to your organization

The trigger determines what data is available at the start of the run. For example, an Email Processing run has the full inbound message in {{email.*}} variables; a scheduled task has no triggering data and starts with only {{meta.*}} variables.

Rule or Task​

A rule belongs to Email Processing: it has a condition and an ordered list of action steps for processing incoming email. Email rules run top-to-bottom in order, and every matching rule runs unless a Stop action halts processing.

Each email rule has an optional Expression that controls whether it runs. If the expression is empty, the rule runs for every incoming email. Otherwise, it runs only when the expression evaluates to true.

Scheduled tasks, forms, and PSA event subscriptions have their own action lists; they are not email rules.

Learn more → Expression Builder

Action Steps​

An action is an operation from the action library, such as Create Autotask Ticket. An action step is one configured use of that action. You can use the same action in several steps with different settings.

Action steps execute top-to-bottom in order. Each step can also have its own optional expression ("only run if..."), so you can make individual steps conditional.

Actions come from the shared Actions library. Your subscription and the type of automation determine which actions you can choose. For example, email-specific actions are available only in Email Processing, while macros are included with Developer Toolkit.

When you store a step's results in a named variable, later steps in the same action list can use that variable. This lets you build multi-step automations: look something up in one step and use the result in the next.

How Rules and Steps Stop​

In Email Processing, every matching rule runs by default, subject to each step's conditions. To stop processing early, use a Stop action:

Stop actionEffect
Stop processing this rule setStops remaining steps in the current rule. Other matching rules continue.
Stop processing this message completelyHard stop. No further rules or steps run for this trigger.

Email automations commonly end with a Stop action. For example, after creating a ticket, you stop so that no further email rules accidentally create a second ticket for the same message.

The most common mistake

Forgetting to add a Stop action. Without it, every matching rule fires. In a standard support mailbox with an Update rule and a Create rule, if the Update rule succeeds but does not stop, the Create rule will also run and create a second ticket.

Variables and Data Flow​

Every action step can store its results in a named variable using the Store results in variable field. The variable is then accessible in all subsequent steps using {{custom.variableName}}.

Every variable name starts with a group name, such as custom or email. Some groups are filled in automatically before your action steps run; others hold the results your steps store.

Variable groupSet byAvailable in
emailAutomatically, from the inbound emailEmail Processing only
inputAutomatically, from the calling automation or the submitted formMacros, Forms
metaAutomaticallyAll automations (properties vary)
customYouAll automations
globalYouEmail Processing only (persists across rules for the same email)
outputYouMacros only

Full reference → Variables

Chaining steps​

The output of each step accumulates as the action list runs. Step 3 can reference variables set by steps 1 and 2. In Email Processing, custom variables reset between rules; use global to share data across rules for the same email.

The { shortcut​

In any text field inside an action step, type { to open the variable autocomplete menu. Every available variable (email data, metadata, and anything stored in previous steps) appears in the list.

Inspecting variables in the processing log​

Every run appears in History with a complete execution log. For each step, you can see the exact state of every custom.* variable (and every other variable) before and after the step runs. This makes it straightforward to understand exactly what data is available at each point in the automation.

Workflow Actions vs. API Call Actions​

Every PSA integration in MSPintegrations provides two categories of actions.

Workflow actions​

Workflow actions contain built-in business logic and perform multiple API calls behind the scenes. They accept high-level inputs (like an email address) and handle the full lookup-and-create process automatically.

Examples:

  • Create Autotask Ticket: searches for the sender as a Contact, finds the Account, creates the ticket, and attaches files.
  • Update Existing Autotask Ticket: scans the email for a ticket number, finds the ticket, adds a note, and updates the status.
  • Create Autotask Ticket (by Configuration Item): extracts a device identifier from the email, finds the matching CI, and creates the ticket under the CI's account.

Use workflow actions when you are processing standard incoming email and want MSPintegrations to handle the matching and routing logic for you.

API call actions​

API call actions make a single, direct call to the PSA API. You provide all the parameters. No additional lookup logic is included.

Examples:

  • API: Create an Object: creates any PSA entity with the exact fields you specify.
  • API: Update an Object: updates any entity by ID.
  • API: Query for One Object: searches the PSA and returns the top result.
  • API: Query for Object(s): searches the PSA and returns an array of results.

Use API call actions when you already have all the required IDs (from a previous step), when you need to work with entity types not covered by workflow actions, or when you are building custom multi-step logic.

Choosing between them: Start with workflow actions for standard support email processing. For custom automations (monitoring alerts, scheduled tasks, multi-step sequences), use API call actions chained together.

Full comparison → Workflow Actions vs. Single API Call Actions

The Processing Log​

Every trigger that arrives is recorded in History. Each entry has a full execution log showing:

  • Which email rules matched and in what order, for Email Processing
  • Every action step that ran, with its configuration at the time it ran
  • Every API call made to your PSA or other systems, including the payload sent and the response received
  • The state of all custom.* and other variables at each step
  • Any errors or exceptions, including the exact error message from the upstream API

This log is the primary tool for understanding why something worked or did not work. When troubleshooting, open the history entry, expand the steps, and read what happened.

Replay: The Play button on a history entry re-processes the same trigger through your current automation configuration. You do not need to send a new test email, wait for the next scheduled occurrence, or resubmit a form. Just replay the existing entry.

Learn more → Exceptions and Retries

Dedicated Triggers per Integration​

A key principle for keeping your automations maintainable: use a dedicated trigger for each third-party tool or use case.

In Email Processing, this means dedicated mailboxes:

The same principle applies to Scheduled Tasks (one task per purpose), Forms (one form per intake reason), and PSA Workflows (one event subscription per purpose, with conditions that select the relevant events).

This keeps each automation simpler, makes History easier to read, and helps you troubleshoot one use case without changing another.

What's Next​