An agent preparing a renewal brief finds a company in Salesforce and a similar name in Stripe, combines the records, drafts a confident recommendation, and proposes an account update. The two records belong to different subsidiaries. The retrieval worked; the join was the mistake.

Account work crosses systems whose identifiers, ownership, and meanings differ. An agent has to resolve those differences before turning a plausible match into a customer fact. This workflow uses the Salesforce and Stripe connections without adding manual cleanup.

Define the customer relationship you are investigating#

“Customer” can mean a legal entity, a sales account, a billing customer, a product tenant, or a person buying on behalf of a company. Decide which relationship the task needs.

For a renewal brief, identify the Salesforce account and the billing customer on that agreement. Use an approved stored mapping if one exists; otherwise ask for it instead of guessing from a shared name or email domain. A proposed mapping carries its evidence:

Both identifiers.
The reason they are associated.
Who confirmed it.
Any scope restriction.

An account can have several billing relationships; collapsing them early hides what the renewal owner needs.

Retrieve enough to answer the question#

Start with a narrow account search, resolve ambiguous matches before any update, then inspect the relevant contacts and their account relationships.

The Salesforce connector’s account search uses selected fields and limited input, not arbitrary SOQL. The operation reference lists the search and update inputs. Salesforce’s query documentation explains how results can require continuation, so a limited response does not mean no other matching record exists.

On the billing side, keep the customer and charge identifiers with the retrieved information, and state the account, period, and currency. A customer record does not show that a payment succeeded, and a charge list is not a complete statement of every commercial obligation. The Deixic Stripe connection reads customers and charges; that access supplies no refund or subscription-management action.

Keep facts and decisions in separate columns#

For a renewal review, ask the agent for this structure:

Question	Evidence to retain	Decision still needed
Which company is this?	Salesforce account ID and approved billing-customer mapping	Resolve subsidiaries or multiple billing accounts
Who should receive the follow-up?	Contact ID and account relationship	Confirm the commercial owner and intended recipient
What payment activity was inspected?	Charge IDs, statuses, currency, and time window	Decide whether other billing records are needed
What should change in Salesforce?	Existing record ID and proposed field changes	Approve the specific update

The table gives the reviewer something to inspect and a second agent enough to continue without repeating discovery.

Keep an unresolved question unresolved. "The retrieved charges do not establish the answer" is a usable finding; an invented explanation for missing evidence creates a new problem for the account owner.

Propose updates instead of creating accounts#

A missing search result can mean an incomplete query, an access restriction, or a different account name. None justifies creating a customer, so resolve those possibilities first.

Before an update, show the existing identifier, old and proposed values, and why they change. If another person edited the record while the proposal waited, re-read it before execution.

For calls through Deixic, apply the relevant approval policy to the proposed action, so the approver decides on a named account and concrete changes, not a vague "clean up the CRM."

Treat retry behavior as part of the workflow#

After an uncertain create or update response, inspect the destination before repeating the action, and retain the result of a completed attempt, including the object identifier.

Stripe documents idempotent requests for supported API operations: a retry reuses an idempotency key and avoids creating a new operation. A separate authorized service that handles billing writes needs its own explicit retry behavior, apart from this brief-building task.

Test the ambiguity before trusting the polished summary#

Test with:

Two similarly named companies.
One company with multiple billing customers.
A contact who moved accounts.
An incomplete query response.
A write whose result is unknown.

Check that the agent asks the narrow unresolved question, preserves identifiers, and creates no second record.

Save the reviewed account-matching procedure as reusable instructions and confirmed mappings within their intended scope. The next agent inherits the method and references, and refreshes payment activity and other changing facts.