Running AppConnect Recipes
Everything between a built recipe and a recipe running reliably: testing it, starting and stopping it, skipping steps while you develop, and reading the jobs report when something goes wrong.
On this page:
Test mode
Test mode picks up a single trigger event and runs it through the recipe, creating a job you can inspect for correctness.
Move the Recipe/Test Jobs slider to Test Mode to enter it, and back to Recipes to return to build mode.
⚠️ Test before starting. Turning on automation that moves data incorrectly creates cleanup work in the connected apps, not just in AppConnect.
Which event gets picked up depends on the When first started, this Recipe should pick up events from configuration. Events process in chronological order, so the earliest matching event is the one tested.
⚠️ The Since/From date locks after the first test or start. It cannot be changed for that recipe afterwards, so it is worth getting right before the first test rather than the first run.
Cancel a running test with the cancel button in test mode.
Reading the result
A successful test shows the path the recipe took, plus Input, Output and Debug information.
A failed test highlights the step where the error occurred with a description. Click the step for detail, fix it in build mode, and repeat the test.
Workato Recipe Test Job Execution Results
Failed Recipe Action with 404 Error
Test jobs and repeat jobs
A test job uses new trigger data from the trigger application. A repeat job reuses the same trigger data. Test mode shows both the test job number and the repeat number.
See all test jobs opens the full job table, and the repeat history for any test job is in its dropdown.
Testing practice
- Use sandboxes rather than production accounts, so the data is realistic without being mission-critical.
- Build incrementally and test at logical intervals. Small segments at a time keeps the flow coherent, keeps datapills mapped correctly, and makes debugging tractable. Skip step is the mechanism for this.
- Test all possible scenarios. Conditional logic means several paths; check none is missing, such as handling both the case where an email is present and where it is not.
- Test every mapped data field and pill, to confirm data is transformed and moved correctly.
Skip step
Skip makes the recipe ignore an action, or a block of actions, at runtime. Three uses:
- Building incrementally. Lay out the high-level logic, then skip everything you are not currently configuring.
- Iterating between approaches. Take turns skipping each version to compare them.
- Working around faulty steps. Design-time errors from broken connections, wrong formulas or missing configuration can be skipped so the rest of the recipe still tests.
Hover over an action and click the Skip step icon. A skipped step is hashed out, and Unskip step returns it. With a step selected, Cmd + / or Ctrl + / toggles it.
Skip Step Option in Conditional Workflow
Unskip Step Option in Automation Workflow
⚠️ Triggers cannot be skipped. A trigger is required to start the recipe.
⚠️ Datapills from a skipped step are unavailable downstream, and dependent steps break. Any subsequent action referencing a pill from a skipped step returns an error when the recipe runs. Skipping a step in the middle of a chain does not quietly no-op; it breaks everything after it that depended on it.
Skipping a block
Skip mode applies to conditional blocks, repeat blocks and error monitor blocks. Select skip on the parent step and every nested step is skipped with it, which matches how control flow works: a conditional statement and its conditional actions belong together.
⚠️ A nested step inside a skipped block cannot be individually unskipped. Unskip has to be done from the parent. It is either the whole block, or the block stays active and you skip its children directly.
Starting a recipe
Starting makes a recipe active and it begins picking up trigger events.
On first start it fetches events per the When first started, this Recipe should pick up events from configuration, then processes continuously.
ℹ️ Events picked up during testing are not reprocessed on start, which prevents duplicate data in your apps.
The Start button shows by default once there are successful jobs; otherwise it is in the dropdown.
Starting again after a stop
For most recipes, starting after a stop continues from where it left off. Stopped on Monday and started on Thursday means every event since Monday is fetched and processed.
⚠️ Webhook-powered real-time triggers may lose everything that happened while stopped. Events occurring during the stop might never be picked up. This is the one case where stopping a recipe loses data rather than deferring it.
Stopping a recipe
Stopping makes a recipe inactive and it stops picking up trigger events.
ℹ️ A recipe has to be stopped to change it, or even to rename it.
Stop Recipe Confirmation Dialog Box
Recipes AppConnect stops for you
Two causes, and an email is sent in both cases:
- The monthly transaction limit was hit.
- 60 consecutive errors fetching trigger events. Causes include a password change breaking the connection, or the app’s API server being down. The underlying problem has to be fixed before the recipe will work.
Long actions
Long actions handle bulk data and take minutes to hours depending on volume, which is why cancelling a job matters when one is in the recipe.
| Connector | Action |
|---|---|
| Anaplan | Run data import, Run data export, Run deletion, Run process |
| Scheduler | Wait |
| Marketo | Bulk export leads to file, Bulk import leads from file, Bulk export activities to file |
| NetSuite | Add/Create in bulk |
| QuickBooks | Wait for paid invoice |
| SAP | Send IDoc |
| SurveyMonkey | Send survey invite via email and wait for response |
| People Task | Request task approval |
| Google BigQuery | Insert rows, Select rows, Select rows using custom SQL |
| Zendesk | Create/update object/record, bulk upsert |
Tasks
A task is a unit of work occurring each time a recipe performs an action requiring compute. Every invocation of a connector action counts as one, AppConnect’s own utilities included, such as lookup tables and Variables.
A job may consist of many tasks. How many depends on the trigger event’s data and the recipe’s logic.
Steps using platform connectors, custom connectors from the Community Library or built in-house, and AppConnect utilities such as the JSON parser, Variables and lookup tables all count.
Counting rules
Successfully run actions count; failed actions do not.
| Action | Counted |
|---|---|
| Trigger | No |
| Trigger conditions | No |
| Control statement (If, Error monitor, Stop) | No |
| Search / Create / Update / Get / Upsert / Lookup | 1 per action |
| Actions inside a repeat loop | 1 per action, per iteration |
| Batch or bulk operations | 1 |
| Callable recipes | 1 for the call, then the called recipe’s actions count in the child job |
| Rerunning jobs | All actions in the rerun count |
⚠️ A failed job still consumes tasks for the steps that succeeded. A job failing at step 5 has already counted steps 1 through 4. Debugging a broken recipe repeatedly is not free.
Jobs
An active recipe processing a trigger event creates a job, holding that one event and executing the recipe logic against its data.
The jobs report
A record of every processed job, with execution flow and the data in and out of each step, plus dates, times and job IDs.
⚠️ The jobs report is not permanent. It retains data only for the duration set by your account’s data retention policy.
Custom reports
The report can show any data available in the recipe, so a recipe processing invoices can display Invoice ID and amount as columns. Click Customize report and use datapills from any data tree in the recipe.
⚠️ Custom reports cannot be created while the recipe is active. Stop the recipe, configure the report, then start it again.
Job details
The top of the page holds job metadata: job ID, repeat number, the recipe version the job ran on, and status. The bottom holds execution details, expandable per step to see input and output.
Useful for two things: confirming during testing that a job completed in the way you intended rather than merely completing, and understanding at which step and why a job failed.
Workato Job Details for Insightly Entity Update
Job statuses
| Status | Meaning |
|---|---|
| Completed | Processed successfully. |
| Failed | Ended on an error, generally a failed action such as an unreachable app or a contact that already exists. |
| Processing | Still running. |
| Paused | A job containing long actions that was paused when the recipe was stopped. |
| Aborted | Rare. Occurs where a recipe has pending jobs and has been changed such that they cannot finish. |
⚠️ A failed job stops immediately and can leave incomplete records behind. Downstream steps do not execute, so a job that failed halfway may have created partial records in the connected apps. This is what the error monitor block’s rollback exists for.
Paused jobs and recipe versions
Stopping a recipe pauses any job in the processing state, and those resume when the recipe restarts.
⚠️ Paused jobs resume on the recipe version they started with, not the current one. Editing and saving the recipe creates a new version, but a paused job finishes on the old one. New jobs after the restart use the new version, so two versions run concurrently for a period.
Reading conditional and repeat steps in job details
An expanded conditional action has a single Output tab showing whether it evaluated true or false. False means the nested actions did not run and the recipe moved on, shown as Condition was not met.
⚠️ Repeat steps only show the last iteration. A foreach over 10 items displays the tenth in job details, not all ten. When an error occurs inside a repeat, you see only the iteration that failed and none of the ones before it, which makes debugging a loop over a large list considerably harder than it looks.
Timeouts
⚠️ 90 seconds per step, 90 minutes per job. Exceeding either times the job out, and the error message says so explicitly. Hitting these means optimizing the recipe rather than retrying it.
Rerunning jobs
Any job can be rerun, completed or failed. AppConnect stores the trigger event data and reruns against that copy. Useful after editing a recipe you want to test, or after fixing whatever caused a job to fail.
⚠️ Reruns always use the latest recipe version. If the recipe changed since the job first ran, the rerun uses the current version, not the one the job originally executed.
Read-only mode
Read-only mode shows recipe, job, version and connection detail without risk of accidentally editing anything.
Recipe. Clicking a step shows its details on the canvas, and hovering a datapill shows where it came from. The data tree is not visible in this mode; Edit Recipe opens the editor for that.
Jobs. All jobs in a customizable format, showing job ID, start date, contact name, and whether the job was a test, production or repeated job. Clicking any job opens its details.
Versions. Every save creates a version, numbered and listed here. Any previous version can be viewed and restored at any time.