Automation playbooks

Use this guide once submissions are already landing in Mountly and the manual process is starting to repeat itself. Good automation begins with a workflow the team already understands, not with a vague plan to "connect everything." The first goal is to move one dependable path into a system you can trust and maintain.

Write down the manual path first

Every durable integration starts with a manual process that somebody can describe. Maybe the team opens recent entries, checks that the payload looks complete, and then copies the relevant data into a CRM or internal system. Whatever that sequence is, write it down before you touch the API.

This step matters because automation should preserve an understood workflow, not invent one by accident. If nobody can explain what happens after a submission arrives, the integration will end up encoding guesswork.

Pick one destination for the first workflow

The narrowest useful automation is usually the best first one. Send new entries to one CRM, one spreadsheet, one internal review flow, or one back-office tool. Resist the urge to design an all-encompassing pipeline on the first pass.

The reason is practical: when the source data, token scope, transformation logic, and downstream assumptions all change at once, it becomes hard to tell which piece failed. A single destination is small enough to verify end to end and valuable enough to remove real manual effort.

Create a dedicated token with a clear owner

Treat the integration token as part of the workflow, not as an implementation detail. It should have a clear purpose, belong to the correct site or environment, and have an obvious owner inside the team. Document what it is allowed to do and how it should be rotated if ownership changes.

That kind of documentation may feel optional when the integration is new, but it becomes important the first time a secret needs to be replaced or a teammate has to decide whether an old automation is still safe to keep around.

Implement one workflow end to end

A good first automation usually follows a simple pattern. Read the new data from Mountly, reshape it into the format the downstream system expects, send it where it needs to go, and record enough information to see when something breaks.

That structure sounds simple because it should be simple. The goal is not to build a platform on day one. The goal is to move one real operational task out of copy-and-paste territory and into a repeatable system the team can observe.

Watch the automation after it goes live

Launching the integration is only the midpoint. After it is running, keep an eye on the obvious signals: submission volume, sudden drop-offs, repeated validation failures, or downstream jobs that stop keeping up. You do not need elaborate observability to start; you just need enough visibility to notice when the workflow drifts away from healthy behavior.

If the team can tell whether the automation is working without digging through secrets or source code, you have already done an important part of the job well.

Next step

Open the API reference when you are ready to implement or tighten the integration contract around that workflow.