Make

Make connects AppBO to other systems through a visual scenario canvas rather than a linear step list. On the AppBO side it watches for events and performs actions much as any automation platform does. What distinguishes it is the middle: routers that split flow down several conditional paths, iterators that expand an array into individual items, aggregators that collapse many items back into one, and error handlers attached to specific modules. The canvas is a dataflow graph, not a checklist.

You choose Make over a simpler tool when the logic has shape. Fan a single AppBO event out to three systems with different rules for each. Take an order payload containing a line-item array, iterate it, look each product up, and write one summarized note back to the contact. Retry just the fragile third-party call while letting the rest of the scenario proceed. Branch on five service types where a linear tool would need five separate automations kept painfully in sync.

It occupies a middle ground deliberately. Compared with a code-based integration it is faster to build, visible to non-developers and self-documenting on the canvas. Compared with a simpler linear automation it demands more care: the same power that lets you iterate a thousand items also lets you consume an enormous number of operations by accident, and a scenario with twelve modules and three routers needs the same review discipline as code.

1. Sketch the scenario before you build it: the trigger, every branch condition, which modules each branch needs, and what happens when each external call fails. Building a router-heavy scenario by improvisation produces something nobody can maintain.
2. Create a new scenario and add the AppBO module as the first module, choosing a trigger type. An instant trigger (webhook-driven) where available, a polling trigger otherwise. Instant triggers are both faster and far cheaper in operations.
3. Create the connection to the AppBO account. Complete the authorization flow, selecting the specific sub-account, and name the connection after that sub-account so later modules are unambiguous.
4. Run the scenario once in manual mode to pull a real bundle of data. Inspect the output bundle in full; the field structure Make learns here is what every downstream mapping references.
5. Add a filter on the connection leaving the trigger, so bundles you do not care about stop immediately instead of traversing the whole scenario.
6. Add a router where the logic diverges, and give every route an explicit filter, including a fallback route for bundles that match nothing. An unhandled bundle silently vanishing is a bug you will find weeks later.
7. Where the payload contains an array, add an iterator to expand it, and remember that everything after the iterator runs once per item. Add an aggregator afterwards if the next step needs one combined value instead of many.
8. Add a search module before any create module. Look the record up by a stable key, and route the found and not-found cases separately rather than letting a create run unconditionally.
9. Map fields explicitly, using Make's functions to normalize as you map: format dates, strip formatting from phone numbers, coerce text to number where the destination is strict.
10. Attach an error handler to every module that calls an external service. Choose the directive deliberately. Retry the transient ones, resume with a default where a missing value is tolerable, and route to a notification branch where a human must intervene.
11. Enable sequential processing and set the maximum cycles deliberately if order matters or if a downstream system cannot cope with parallel writes.
12. Test each branch in manual runs, forcing bundles down each route in turn. Read the execution inspector for every module, not just the last one.
13. Verify the connection is live by triggering a real event and watching it appear in the scenario's execution history with the expected route taken and the expected records written.
14. Force a failure on purpose (point one module at a bad credential) and confirm the error handler does what you designed rather than halting the scenario.
15. Schedule or activate the scenario, set the operations and error notifications, and review the execution history daily for the first week.

Platform to Make

• Trigger bundles for the events the AppBO Make modules expose. New and updated contacts, opportunity and pipeline changes, form submissions, appointments and inbound messages. Confirm the available triggers in the app's module list.
• Full records retrieved by search and get modules, including custom field values.
• Arrays that an iterator can expand: submission answers, line items, tag lists, search result sets.

Make to the platform

• Contact creates and updates, with standard and custom fields, tags and owner.
• Opportunity creates and stage changes.
• Notes, tasks and appointment records.
• Workflow entry for a contact.
• Arbitrary API calls via Make's generic HTTP module, for anything the dedicated modules do not cover: carrying the connection's token.

Between Make and third parties

• Whatever the paired app's modules expose, in both directions, with Make holding a separate connection and credential per app.

What does not move

• Operations and execution state are Make's own; the platform has no visibility into whether a scenario ran.
• Builder assets: funnel pages, email template design, site structure.
• Bulk historical loads. A scenario can be made to iterate thousands of records, but the operations cost makes a direct import the better tool.
• Transactional guarantees. A scenario that fails at module seven does not undo modules one through six.

Scenario: a form submission in AppBO must be routed to one of three destination systems by service type, with the submission's answer array summarized onto the contact as a single note.

1. The scenario's first module is the AppBO instant trigger for a form submission, connected to the clinic sub-account and filtered to the intake form.
2. A patient submits the intake form. The trigger fires within seconds and emits one bundle containing the contact details and an array of question-and-answer pairs.
3. The filter on the first connection checks that the email field is non-empty. Blank submissions stop here, costing one operation.
4. An iterator expands the answer array into individual bundles: eleven answers, eleven bundles.
5. An aggregator immediately collapses them back into a single text value, one line per answer, formatted for readability. This iterate-then-aggregate pair is how you turn an array into something a note field can hold.
6. An AppBO module writes that text as a note on the contact, so the clinical team sees the full submission in context.
7. A router splits on the service type answer into three routes, each with an explicit filter, plus a fourth fallback route.
8. Route one maps the patient into the external scheduling system via its own module. Route two creates a record in the laboratory portal over the generic HTTP module, because no dedicated module exists. Route three raises a task in the practice management tool. The fallback route posts to an internal notification channel saying a submission did not match any service type, with the contact identifier.
9. The laboratory portal is intermittently slow, so that HTTP module carries an error handler set to retry with a backoff. The first attempt times out; the second succeeds, and the rest of the scenario is unaffected.
10. A week later the laboratory portal rotates its credential. The HTTP module now fails permanently; its error handler routes to the notification branch rather than retrying forever, and an operator is told which submission needs replaying.
11. You update the credential and re-run the two stored incomplete executions from the scenario's history, which replays only the failed portion rather than re-sending the note or re-routing the other systems.

Operations and rate limiting

Make bills in operations, and an operation is roughly a module processing one bundle. An iterator over a large array multiplies every subsequent module by the item count, which is how a scenario that looked cheap in testing consumes a month's allowance in an afternoon. Filter before iterating, aggregate as early as the logic allows, and set a maximum cycle count. Separately, every AppBO module call counts against the account's API rate budget, so a scenario looping over thousands of contacts can trip 429 responses regardless of your operations balance.

Retries and idempotency

Error handlers give you real control, and with it real responsibility. A retry directive on a create module will happily create a second record if the first attempt actually succeeded before timing out. Put a search module in front of every create, and prefer update-or-create semantics. Make's incomplete-executions store is genuinely useful here, but replaying a stored execution re-runs the modules from the failure point, so those modules need to tolerate having partially run.

Field mapping traps

Mappings are bound to the structure Make learned from the sample bundle; a field missing from that sample is not available in the mapping picker, and a field that changes shape upstream silently maps to nothing. Make is strict about types in places (a text value where a number is expected will error rather than coerce) so use the formatting functions deliberately. After an iterator, mappings that reference the pre-iterator bundle still work but mean something different from the per-item values; mixing the two is a common source of wrong output.

Duplicate creation

Routers make this worse than in a linear tool: two routes whose filters both pass will both run, and if both end in a create you get two records. Make route filters mutually exclusive, and test by forcing a bundle that could match more than one.

Sandbox versus live

Manual runs write real data. Use a test sub-account and test credentials for the paired systems, and remember that a manual run of a scenario containing a messaging module sends a real message. Clone the scenario to experiment rather than editing a live one.

Auth expiry

Connections hold tokens that expire or get revoked. Make will surface an authentication error and, after repeated failures, deactivate the scenario. Connections created under an individual's login die with that login, so create them under a shared team identity and route error notifications to a shared mailbox.

What commonly breaks

• A router with no fallback route, silently dropping bundles that match nothing.
• An iterator left in place after the upstream payload stopped being an array.
• Operations exhausted mid-month, deactivating every scenario at once.
• A live scenario edited in place while executions are in flight.
• Parallel processing writing to a destination that needs ordered updates.
• Error handlers added to the easy modules and forgotten on the fragile one.