AI in Practice

Before an AI Feature Uses Salesforce, Define the Answer

On October 6, 2026, Ampersand announced a $15 million Series A and introduced Andi in beta. The company says Andi helps developers get products running in customer environments.

By Demetri Panici

October 14, 2026

13 min read

A bounded Salesforce request passes through a clear boundary and becomes a concise answer card.

On this page

What Andi’s beta makes worth specifying
Start with the answer your feature should return
Map product concepts to the customer’s fields
Connect the customer’s Salesforce org with a clear identity
Decide what “current enough” means
Keep writeback out of the first feature unless it is needed
Make the first result checkable
Keep the product contract with the product team
Write the one-page brief before expanding

On October 6, 2026, Ampersand announced a $15 million Series A and introduced Andi in beta. Ampersand says Andi helps developers with the implementation work of getting products running in each customer’s environment (Ampersand announcement). That makes one product question timely: before using implementation help on a Salesforce-backed feature, what outcome, data, and checks should the team specify?

Ampersand describes customer-specific mappings alongside read, write, search, and event actions (Ampersand overview). These vendor materials establish what the company documents, not whether a particular tool fits or has been tested for a feature. This article uses a hypothetical Salesforce sales-research task to show what a product team can specify and verify.

What Andi’s beta makes worth specifying

Two customers may represent the same business concept, such as account industry, in different Salesforce fields or objects. An implementation assistant may change how a team approaches that setup, but the announcement does not specify which steps Andi performs, which customer configurations it supports, or how a team should verify its proposed mapping (Ampersand announcement; Ampersand overview).

A team evaluating an implementation assistant can bring one feature task and ask three things: what output and field mapping does it propose, which product choices remain for the team (required data, missing-field behavior, and authorization), and what will show that the result is correct in that customer’s environment? These are evaluation questions, not a description of Andi’s current workflow or a claim that the hypothetical task has been implemented.

Start with the answer your feature should return

Before choosing an integration tool, write down what the user should receive. For a hypothetical sales-research feature, the output might be a short account and opportunity brief that helps a salesperson prepare for a meeting. The brief could summarize a few relevant CRM fields, link back to the source records, and say when the information was retrieved if the product can support that statement.

A product builder reaches toward a small group of abstract shapes while defining what belongs in a concise feature response.

That description is a proposed product contract, not an Ampersand capability. It gives the team a way to work backward from the user’s question. A product specification might say:

The user selects or supplies an account identifier.
The feature looks up the account and a limited set of related opportunities.
The brief returns only fields that support the stated task.
Each fact can be traced to a source record or is clearly identified as an inference.
If a required field or record is unavailable, the feature says what is missing instead of filling the gap with a guess.
The product describes retrieval timing only when it can determine and support it.

A useful specification also defines the shape of an incomplete answer. If a record cannot be found, does the product return a clear “no matching account” state? If an optional field is blank, can the brief still be useful? If a required value is missing, should the feature stop, ask the user to choose a record, or return a narrower result? These are product decisions. The integration layer cannot make an unclear feature request precise on the team’s behalf.

Three proposed responses to incomplete account data: stop if no matching record is found; continue with an optional field blank; and pause to resolve a missing required value, by asking the user or returning a narrower brief.

Starting with the output also helps limit the first implementation. “Give me context about this account” can expand into every object and field a customer has ever added to Salesforce. “Summarize this account’s industry, current status, and two active opportunities” is a more bounded request. The exact fields will depend on the customer’s Salesforce configuration, so the product needs to specify which values are essential and what it will do when a customer’s setup does not contain them.

The point is to turn an open-ended agent idea into a request with a target, a limited data need, and an observable response. Once the output is clear, the next question is where its values live.

A terracotta request marker passes through a narrow cream opening toward a bounded response with two marks.

Map product concepts to the customer’s fields

A product may use a familiar concept such as “account industry,” while a customer’s Salesforce org stores the relevant value in a standard field, a custom field, or a combination of fields. Ampersand’s overview describes customer-specific mappings as part of its platform model (Ampersand overview). That is a vendor description of the product, not evidence that every customer schema can be mapped automatically or without review.

A team can make the mapping problem explicit with a small table before it builds the feature:

Account name: Needed for the answer?: Required; Possible Salesforce source: Account name field; If it is missing: Ask the user to select a valid account or return a no-match state
Account industry: Needed for the answer?: Optional for this example; Possible Salesforce source: Standard or customer-selected field; If it is missing: Omit it and disclose that the brief has limited context
Opportunity stage: Needed for the answer?: Required for an opportunity summary; Possible Salesforce source: Opportunity stage field; If it is missing: Exclude that opportunity from the summary or report the missing value
Expected close date: Needed for the answer?: Optional; Possible Salesforce source: Standard or customer-selected field; If it is missing: Omit it; do not infer a date

These rows are illustrative, not a prescription for Salesforce field names. A real product team should identify the concepts its answer uses, ask which source values satisfy them, and make missing-data behavior part of the contract.

Separate required values from helpful extras. If the feature’s core purpose depends on a valid opportunity stage, a missing stage may make the answer incomplete. If an industry field only adds color, its absence may not need to block the whole brief. The distinction prevents a common design mistake: treating every unmapped field as either harmless or fatal without considering how it changes the user’s decision.

The contract should also keep customer configuration visible to the product team. If one customer maps “industry” to a custom field and another uses a standard field, the normalized product concept can remain the same while the source mapping differs. That does not mean a mapping is correct just because it exists. The team still needs a way to confirm that the chosen source value means what the feature expects and that the user understands when it is unavailable.

Two different customer source shapes approach one shared concept, with visible gaps between them.

This is a good place to define a small set of schema states: mapped and present, mapped but blank, not mapped, and not accessible to the connected identity. Those states may require different user messages or setup steps. Treating all four as an empty string hides information the product needs in order to respond honestly.

Once a team knows which values it needs, it can ask for access that fits the task. The connection is part of the feature design, not a box to check after the agent prompt is finished.

Connect the customer’s Salesforce org with a clear identity

A Salesforce connection involves more than a button that says “Connect.” The product team and the customer administrator need to know which org is being connected, which identity is used, what access is granted, and who can change that access later.

Salesforce documents an API-only integration-user option and recommends using a different user for each integration, calling system, domain, use case, or API resource. Salesforce also notes edition and setup considerations for this feature (Salesforce integration-user guidance). The current Salesforce guidance should be checked for the customer’s edition and setup before relying on that option. The recommendation does not establish that every org has the same configuration or that a separate user per SaaS tenant is mandatory.

Keep three identities distinct in the design:

The Salesforce integration identity is the user or authorization context Salesforce sees when the application accesses the org.
The product’s end-user identity identifies the person using the SaaS feature.
The integration installation or connection record is how the product represents a particular customer’s configured connection.

Those identities may be related by the product’s architecture, but they are not interchangeable. A signed-in salesperson does not automatically tell Salesforce which API identity is making a request. Similarly, the existence of an installation record does not tell a reader which fields that identity can access.

Separate symbols represent a signed-in salesperson, an API identity, and an installation record.

A practical connection preflight can ask the customer administrator to confirm the intended org, approve the app’s requested authorization, and verify that the integration identity can see the records and fields needed for the feature. The product should explain what it needs in terms the administrator can review. If the requested brief needs an account name and opportunity stage, the setup should not quietly ask for broad access without a reason tied to the product task.

The exact OAuth flow and setup steps depend on the current product and provider documentation. Ampersand’s AI SDK documentation lists connection and installation checks and OAuth initiation among its documented tools, and labels the SDK Alpha (Ampersand AI SDK). That tells a reader what the vendor documents and the maturity label it gives the SDK. It does not establish that a specific OAuth configuration has been performed here, that it is suitable for every deployment, or that the consuming application’s identity model is correct.

Before moving on, a team should be able to answer a basic question: does this connection represent the Salesforce org and identity that the user expects this feature to use? That is a setup condition to verify in the product’s own environment, not a guarantee conferred by the fact that a connection screen returned success.

Decide what “current enough” means

The data path should follow the user’s need. If the feature answers a question on demand, a focused read may be enough. If it must reflect later changes, the team needs to define which changes matter and what the user should observe when they arrive. These are different product requirements, even if an integration platform offers several ways to move data.

A focused leaf under a magnifier sits apart from a three-leaf branch, suggesting an on-demand read and separate later changes.

Salesforce documents query and change-event mechanisms with different provider limits and setup requirements (REST Query, Change Data Capture). Ampersand’s overview also lists on-demand reads, backfills, incremental syncs, and subscriptions (Ampersand overview). Selecting among those mechanisms is a separate technical task. This article focuses on the product requirement that should guide that choice.

For the sales-research example, the product brief can first say: retrieve the selected account’s required values when the user requests a brief, and show when those values were retrieved if the product can support that. If the feature later needs to react to a change in a particular opportunity field, name that field and the expected user-visible update. Then the team can choose and test an appropriate provider path against the customer’s edition, object, permissions, and product setup. A successful initial read does not establish that later changes will appear on the schedule the feature promises.

The essential deliverable is a definition the team can verify: which source values are used, when the product retrieves or updates them, and what it tells the user if it cannot confirm the expected state. A change stream is one possible implementation choice, not a substitute for that definition.

Keep writeback out of the first feature unless it is needed

The example is read-first. If a later feature writes to Salesforce, define that as a separate product requirement: identify the target record and field, decide what happens if the target is missing, and specify how the product will present an uncertain result.

An open book and bookmark sit apart from a closed notebook and unused pen, separating the read-first example from a possible later write.

Ampersand’s AI SDK documents create and update tools and currently labels the SDK Alpha, with possible non-backward-compatible changes (Ampersand AI SDK). Salesforce distinguishes updating a record by ID from upserting with an external ID; an upsert can create a record when a match is absent (Salesforce update and upsert). Those facts are enough to show why a team should name the intended write operation before building it. They do not establish that a write has been configured or tested here.

This article does not decide whether an agent should have authority to change CRM records. Rise has covered that question separately in its pieces on AI agent oversight and personal AI agent governance. For this feature decision, the useful boundary is simpler: do not add write access to a read-only job just because the integration SDK exposes a write operation.

Make the first result checkable

A product brief is more useful when the team can describe what it would verify before calling the feature ready. For the hypothetical account brief, a small non-production check could include:

Right customer and record: confirm the selected Salesforce org and test account are the ones the user intended.
Right values: confirm each required product concept comes from the expected configured field, including a customer-specific field when applicable.
Honest gaps: test an unmapped or blank required value and confirm the product reports the limitation instead of filling it in.
Useful output: compare the returned summary with the known source record and confirm that source links let a reviewer inspect the underlying values.
Freshness, if required: change a named test field and check the specific user-visible behavior the product promised.

These are proposed checks, not tests performed for this article. Their purpose is to make the feature’s acceptance criteria concrete before the team interprets a successful connection screen or demo as proof that the user’s task works.

The product should also decide what evidence its team needs when a user-visible result is missing or uncertain. Ampersand’s overview describes operation logs and notifications for integration conditions (Ampersand overview). A product team should still specify what evidence it needs to investigate this feature’s result.

An abstract imprint and detached fragment symbolize evidence a team could investigate when a result is missing or uncertain.

Keep the product contract with the product team

A useful division of responsibility starts with what each party can define:

Feature outcome: Product question: What should the user be able to answer or do?
Data contract: Product question: Which records and values are required, and what happens when they are absent?
Customer setup: Product question: Which Salesforce org and configured identity are intended for the feature?
Provider behavior: Product question: Which documented Salesforce behavior applies to the customer’s edition, objects, and permissions?
Verification: Product question: What can the team observe that demonstrates this specific feature returned the expected result?

Ampersand describes customer-specific mappings and integration actions; Salesforce documents its APIs and org requirements. The customer admin configures access. The SaaS product team still defines the user task, the meaning of its output, and the conditions under which it will present that output as complete.

That is the product-builder decision this article develops. It is not a verdict on whether a team should build or buy integrations, nor a comparison of vendors. The Series A is evidence of Ampersand’s financing and direction, not evidence that a particular product should select it. The beta release of Andi makes the implementation question more concrete, but the fit still depends on the feature and customer configuration a team needs to support.

Write the one-page brief before expanding

The most useful output from this exercise is a compact integration brief for one feature. It can fit on a page:

User question: What should the feature help the user answer or do?
Target record: Which Salesforce record does the user select or identify?
Minimum fields: What values are necessary for the response, and which are optional?
Mapping: Which customer-specific sources provide those values, and how will the product handle missing or inaccessible fields?
Connection: Which org and integration identity are expected, and what does the customer administrator need to confirm?
Read method: Is this a focused request for records or a separate asynchronous data job?
Freshness need: Is on-demand retrieval enough, or must later changes be reflected? What observed behavior would satisfy that need?
Writeback branch: Does the first feature need to write at all? If so, which exact record and field, with what missing-match behavior?
Completion check: What can the team observe that demonstrates this specific workflow returned the expected data and handled failure cases honestly?

The one-page brief gives a product team a concrete way to assess implementation help such as Andi: does a proposal map fields for one real task, expose missing or inaccessible data, and produce a result the team can inspect? Ampersand’s October 6 funding and beta make that question timely. They do not establish that Andi implements this example or fits every customer.