Five routes to the same system
A workflow can connect to a business system in five ways. They differ not in ultimate capability, but in how quickly they are available, how granular permissions are and who maintains them.
1. Native — an existing integration
The system is already supported: actions are predefined, permissions documented and maintenance rests with the integration supplier. This is the fastest route with the fewest surprises.
The limitation matters equally: you get the actions that exist. Asking harder cannot force an action the integration does not support.
2. Configured — existing components, your setup
Existing integrations are combined and configured for your process: which fields, filters and control level. No new code, but real setup work. Most practical solutions use this route.
3. MCP — through an integration standard
Some suppliers expose their system through a standard allowing an agent to discover available actions. Attractive, because you do not depend on a specifically built integration.
Watch two things. Permissions are as granular as the provider made them — often coarser than you want. And you depend on that external server's availability and versions; explicitly identify that supplier dependency.
4. API — directly through the interfaces
If the system has a documented API, you can build exactly the actions needed with exactly the permissions you want to grant. More work, more control and your own maintenance obligation with every version change.
5. Custom — everything else
A system without an API, an internal application, an export arriving by email. Here you build the bridge yourself, potentially using screen operation. This is the most expensive and fragile route; choose it deliberately with an owner, not as a leftover category.
How to choose
Three questions almost always lead to the right route:
- Does an integration for this system already exist? If so, start there and check whether it has the actions needed. If not, continue.
- How granular must permissions be? If you want to release only one folder or object type, a broad-permission route is no option, however fast.
- Who maintains this in a year? Every route except the first assigns maintenance somewhere. If you cannot answer that, the route is too expensive regardless of build costs.
Be honest about what does not exist
A common mistake is promising a "native integration" that does not exist. A system without an existing integration uses MCP, API or custom work — with corresponding timelines and maintenance. For every quote, explicitly ask which route is intended and who maintains it. Current Gen8 routes are documented per system on the integration pages.
Start smaller than you think
A read-only integration is almost always approved faster than one that writes and often already delivers most gains. Starting read-only and adding write permissions later is also a much easier administrator conversation than the reverse.