Why assess first
Most Salesforce rescues and integration programmes start under time pressure. Someone has already promised a go-live date, a partner has rolled off, or a new ERP needs customer data by the end of the quarter. The temptation is to start fixing or building straight away.
That is how teams end up adding a new integration on top of automation nobody fully understands, or patching defects that are symptoms of a data model that no longer fits the business. A short, structured assessment costs days. Skipping it can cost the programme.
The goal is not a 200-page report. It is a clear answer to three questions: what state is the org in, what will fail first under the change you are planning, and what has to be fixed before that change, as opposed to after it.
1. Automation and order of execution
Orgs that have grown over several years usually carry automation from different eras: Workflow Rules and Process Builder, record-triggered Flows, Apex triggers, and sometimes managed-package automation as well. Each piece may be reasonable on its own. Together they can fire in an order nobody planned, update the same fields twice, or recurse.
I map automation per object, not per tool. For the objects your rescue or integration will touch, list every trigger, Flow, legacy rule and package component that runs on insert and update, then walk through what happens when a single record is saved. This is where record-locking errors, unexpected field values and CPU time-outs usually come from.
- Objects with more than one trigger, or triggers without a handler pattern.
- Record-triggered Flows and Apex updating the same fields.
- Workflow Rules and Process Builder still active. Both reached end of support on 31 December 2025: they still run, but Salesforce no longer fixes bugs in them.
- Automation without a bypass mechanism, which makes data loads and integrations much harder.
2. Data model and data volumes
Integration programmes fail on data more often than on code. Before connecting a new system, check whether the data model can hold what the integration will send, and whether the volumes will stay inside what the platform handles comfortably.
Look at record counts on the objects in scope, how fast they are growing, and how they are related. Very large numbers of child records under a single parent, or many records owned by a single user, cause lock contention and slow sharing recalculation. These problems often stay invisible until an integration starts updating records in bulk.
- Record counts and growth for every object in scope.
- Parents with very large numbers of children (data skew) and records concentrated under one owner.
- Queries that filter on fields without selective indexes on large objects.
- Duplicate and incomplete records, and which system is meant to own each field.
3. Security and sharing
A rescue is often the moment when everyone has been given more access than they need, just to get through testing. An integration is the moment a new user, usually a highly privileged integration user, enters the org.
Review the organisation-wide defaults, role hierarchy and sharing rules for the objects in scope, how permissions are granted, and how the integration will authenticate. Integration users should have only the access the integration needs, authenticate through a supported OAuth flow, and keep their credentials out of code and configuration.
4. Limits and headroom
Salesforce enforces limits per transaction and per org. A healthy org has headroom; a struggling one is often already close to a limit somewhere, and a new integration or a burst of data loads pushes it over.
Check the limits that the planned change will consume: API requests per rolling 24 hours, asynchronous Apex executions, data and file storage, and in code, the per-transaction limits on queries, DML statements and CPU time. Look at the Apex exception emails and debug logs from recent weeks too; they show where transactions already fail.
5. Integrations already in place
Most orgs that need a new integration already have several. Document each one: which system is the source of truth for which data, the direction and frequency of synchronisation, how it authenticates, and, most importantly, what happens when it fails. Integrations that fail silently are the ones that cost the most, because the business finds out from a customer.
6. Code quality, tests and release practice
Release practice decides how quickly you can fix whatever the assessment finds. Review how changes reach production, whether sandboxes reflect production, and whether tests assert behaviour or only exist to reach the coverage threshold.
Static analysis tools such as Salesforce Code Analyzer quickly show the shape of the codebase: security issues, anti-patterns and unused code. They do not replace reading the code that sits on the critical path of your change.
Turning findings into a plan
Every finding goes into a single register with the business risk, the effort to fix, and whether it blocks the planned change. That last column is the one that matters. A typical outcome is a short list of things to fix before the integration or go-live, a longer list to schedule afterwards, and a few decisions only leadership can make.
Present the result in plain language to the people funding the programme, with the technical detail in an appendix for the team that will do the work.