A connector logo is not an integration plan

Name the exact action

Replace connect our CRM with a concrete action: read an approved account field, prepare a proposed update, or write an authorized change. Those are different permissions and different failure risks. Specify the record type, audience, purpose and owner. Start with one action that supports the task you actually want completed.

An API existing does not prove the intended action is available on your plan or appropriate for your data. Ask the implementation owner to demonstrate the exact operation with synthetic records. Record the result and any manual work needed. Do not let a list of partner logos substitute for this evidence.

Separate read from write

A workflow allowed to explain a procedure does not automatically need permission to change the underlying system. Write the minimum action required for the first project. For a proposed update, specify who approves it and what happens when the record changes between preparation and approval.

Keep the application identity, permitted audience and approval owner visible to the authorized system reviewers. They determine the actual security controls. This planning method does not grant access or certify a connection as secure.

Inspect the failure contract

Ask what the receiving person sees when the source is unavailable, the request times out or a field is missing. A silent empty value may look like a business fact. Require the workflow to distinguish unavailable evidence from a confirmed absence.

For writes, ask how retries and duplicates are handled. Test a synthetic duplicate request and inspect the final records. A message saying success is not the same as evidence that the intended system accepted the action once. Your system owner approves the relevant technical acceptance tests.

Illustrative editorial photograph, not a customer result.

Define the source-change rule

If a procedure or record changes after a draft is prepared, decide whether the draft becomes stale. Name the person who confirms that decision. Record source versions where the workflow needs them. A scheduled refresh is not a guarantee that every downstream output is current.

Try a controlled source change during the demonstration. Inspect the new result and the old prepared output separately. This often reveals whether the connection retrieves fresh information or merely loads a snapshot at the start of a session.

Put maintenance in the proposal

Record who monitors failures, updates field mappings, handles provider changes and owns the manual fallback. Include setup, ongoing work, usage assumptions and exit requirements. A connection that works once can still depend on recurring manual attention that your team has not budgeted for.

Keep an explicit continue, narrow or stop decision after the trial. Do not expand because the ordinary case worked while the missing-source test remains unresolved. Attach actual test evidence rather than accepting an assertion that errors are handled.

Bring a one-page connection brief

Use these fields: business task; exact read or write; approved sources; audience; acceptance evidence; failure behavior; maintenance owner; manual fallback. Then use the AI Knowledge Access Test Sheet to check the knowledge boundary alongside the connection.

Request a relevant demo with that brief. SimplBrain and separately scoped SimplDev work can support approved workflows, but the team must confirm the actual action and dependencies before implementation.

Your working check