The connector is the easy part. Agreeing who owns the field is the project.

Often not. Nintex's connector library plus custom connectors built on its extensibility framework covers a great deal of process-driven integration, and adding a middleware tier for four integrations is expense without benefit. A dedicated integration platform earns its place when you have high-volume, system-to-system data movement with no human step, complex transformation and mapping across many endpoints, or an existing enterprise integration standard you are required to use. We will tell you which case you are in rather than defaulting to the more expensive one.

It writes back, and for most processes it must — otherwise the automation ends with someone copying an outcome into the CRM by hand, which is the step you were trying to remove. The design question is what it is allowed to write. We keep Salesforce authoritative for customer and deal data, and let the process write only what the process owns: approval outcome, generated document, signature status, stage progression. That boundary is what stops an automation from overwriting a value a human deliberately changed.

In order of preference: find the API that exists but was not documented internally, use a supported file or database interface, or — last — automate the interface a person would use with a bot. Robotic automation is legitimate here and sometimes the only option, but it is materially more fragile than a call and breaks on cosmetic interface changes nobody announced. We design those steps so the process expects them to fail, and we replace them the moment a real interface becomes available.

Whatever the conflict rule says, which is why the rule is agreed before the build. The common options are that the authoritative system always wins, that the most recent change wins, or that a conflict is not resolved automatically at all but raised to a person as an exception. The third is the right answer more often than teams expect — for fields where a silent overwrite would be worse than a short delay. What never works is having no rule, because then the answer is whichever job happened to run last.

Two mechanisms, because one is not enough. Error alerting catches failures that report themselves and routes them to a named owner rather than a log. Scheduled reconciliation catches the failures that do not report themselves — the sync that silently stopped, the records that were skipped, the field that stopped being populated — by comparing both sides and flagging differences. The second is the one most estates lack, and it is the reason divergence usually surfaces during a month-end close.

Work with them, unless there is a specific reason not to. We document what exists, identify which ones have an implicit contract nobody wrote down, and add monitoring and reconciliation where they are missing — which is usually the cheapest meaningful improvement available. Replacement is worth it when an integration fails regularly, has no owner, duplicates another, or blocks something you are about to build. Rebuilding working integrations to a house standard is rarely a good use of the budget.