Integrations and Web Services
Integration objects and connected systems
An integration defines a call to an external system: HTTP, SOAP, or a connected system that centralizes authentication and base URL. The connected system holds credentials and endpoint configuration; the integration holds the request shape (method, path, headers, body) and the response mapping. Integration objects are reusable and can be called from process models, interfaces, and expression rules.
Request and response handling
Responses map to CDTs or dictionaries. Error handling uses the integration's error configuration and the calling node's exception flow. Timeouts and retry behavior should be set deliberately; a missing timeout is a common production issue.
Traps to watch for
- Assuming credentials live in the integration. They belong in the connected system, which keeps secrets out of the design object.
- Confusing an integration with a web service exposed by Appian. The former calls out; the latter is called in.
- Forgetting that response mapping must match the CDT structure, or fields silently arrive empty.
- Believing an integration call in an interface is synchronous-safe for long operations. Long calls belong in a process.
Rule of thumb
Direction decides the object: outbound = integration plus connected system; inbound = web service or API. For outbound calls, always ask where authentication lives (connected system) and what happens on failure (error handling plus exception flow).
Worked example
An integration returns 401 in production but works in test. The connected system uses environment-specific credentials; the production connected system was configured with test credentials. Correcting the connected system's authentication resolves the failure without touching the integration.