Choose around the workflow, not the tool
A workflow platform can connect services and make an operational sequence easier to inspect. A custom integration can place detailed domain logic close to the application that owns it. Some projects need both: an orchestration layer for coordination and a small service for a specialised calculation or data boundary.
Start by drawing one real flow. Identify its trigger, the records it reads, the decisions it makes and the system it updates. Note which step needs a person to approve it. This exposes the requirements that a tool comparison alone misses.
Check ownership and interfaces
For a lead-to-CRM flow, decide which system creates the lead identifier, which fields may be updated and what should happen when a person edits the record during a retry. For orders or invoices, distinguish a proposed action from an approved financial event.
Check the provider's documented API, account permissions and request limits. A connector's existence does not establish that it supports every operation or the features enabled in your account.
Design failure handling before the happy path
Ask what happens after a timeout. The receiving system may have completed an action even if the sender did not receive its response. Use stable identifiers and duplicate checks appropriate to the destination; do not assume that retrying any request is safe.
n8n documents error workflows and execution investigation. Those mechanisms still need a project-specific policy: who receives an alert, what data may be retained, when an operator intervenes and how a failed event is reconciled.
Compare the operating model
A useful comparison covers more than build speed:
- Who owns credentials and can rotate them?
- Who reviews changes before a workflow runs against production?
- Where is execution data stored and who may read it?
- How are versions, backups and recovery demonstrated?
- Who responds when a provider changes an interface?
A visual workflow remains software that needs ownership and maintenance. A custom service needs those controls too. Estimate the running responsibility alongside implementation effort.
Prove one bounded case
Use approved test data to verify one workflow, including an invalid input, duplicate event, unavailable provider and recovery. Agree success criteria and ownership before expanding to additional systems. Timing depends on access, data readiness and the actual business rules.
Discuss n8n automation for orchestration or ERP and CRM integration when record ownership and reconciliation are central. The final approach should follow the workflow and its operational requirements.