A task can run one action every time it runs, or it might run many actions – it all depends on the task.
Mechanic supports different types of actions, which can each be configured to control what actually occurs when the action is run.
The language around actions is super specific, and the distinctions are important!
At the risk of getting circular, when we say "action", we refer to the combination of action type and action options. There's no connection to the event: this combination is the result of running a task script against a given event, and is constructed using the action definitions that the task script renders.
When the action runs, we have (naturally) an action run.
A simple string, indicating what sort of action you wish to execute.
"shopify" are super common!
Each action type requires a certain set of options. Naturally, for an email action, Mechanic wants to know where to send the email, what subject to use, and what to send in the body of the message. Read about each action type to see what options are required.
This is a JSON object that combines the action type with the action options. The task scripts you write in Mechanic are responsible for constructing these definitions.
The structure of an action definition always starts with this:
Those three keys, arranged like so, are mandatory: they tell Mechanic that you wish to construct an action, of a specific type, with specific options.
Filling in the blanks, here's what a fleshed-out definition for an email might look like:
"subject": "Pleased to meet you!",
"body": "Would you like a coffee?"
Note: this is just the resulting JSON, for a single action definition! Mechanic's scripts have the flexibility to specify multiple action definitions, using as much or as little Liquid as you care to leverage. The only requirement is that the final, rendered script be a valid series of JSON objects.
While you won't see this exact term in the Mechanic interface, an "action run" refers to an action definition that's applied to an incoming event. Literally, it represents what Mechanic tried to do, and what happened as a result. You'll see these represented in Mechanic whenever incoming events occur.