Software Proof of Concept in a Salesforce Sandbox

A Funnel Economics proof of concept runs in a sandbox of your Salesforce environment. About four weeks lead to the first result and the go/no-go decision. The opportunity history is read from your production org. During the sandbox phase, no package is installed in the production org and nothing is written. Your administrator creates exactly two things there.

How the proof of concept proceeds

Funnel Economics is entering its beta phase. During the beta, you start by running it against a Salesforce sandbox.

This guide describes the route for Salesforce administrators and IT: what is created in your environment, which data go where, and how the proof of concept ends.

Why a sandbox alone is not enough

Funnel Economics calculates on the history of the opportunities. That history is exactly what a Salesforce sandbox lacks. A Partial Copy sandbox does not copy the stage history.

A Full Copy sandbox copies only the last 180 days of the stage history. That is too short for the time series the evaluation rests on.

The proof of concept therefore reads the history from your production org. Everything after the import is the ordinary product: aggregates, audit data, dashboards and AI commentary.

Four steps to the go/no-go decision

The technical sequence takes about four weeks and has four steps.

1. Stage-mapping workshop. The stage mapping defines which stages of your sales process the evaluation knows.
2. Connecting the sandbox. The package is installed in the sandbox, and the sandbox is connected to your production org.
3. Validation.
4. Handover with go/no-go. The first result is available, and the go/no-go decision is taken.

The four weeks are not the duration of the proof of concept but its first section. After that, the evaluation continues in the sandbox for the rest of the six-month engagement.

Three runs, started by hand

There is no scheduling in the proof of concept. Three runs are started by hand, in a fixed order: load the history, rebuild the aggregates, renew the audit data. After an aborted run, the history is loaded again in full, not resumed.

Which prerequisites you bring

The beta programme is limited to at most five companies. Two technical prerequisites apply to each: a sandbox and your own provider account for the language model. You bear the cost of the language model through that account.

Which sandbox is suitable

The sandbox must be a copy of your production org. The history is matched through the record Id, and a copy keeps the Ids of the production org. Pure developer sandboxes carry no opportunity data and are therefore ruled out.

One Opportunity Type and one subset

The proof of concept models exactly one funnel, that is, exactly one Opportunity Type. Cycle length and model assignment depend on it.

A subset of selected opportunities is loaded. The upper limit is 5,000 opportunities; above it, no run starts.

The recommended size is at most 2,500 opportunities; above it, the runs work but are noticeably slower.

The subset must also sit in mapped stages. If opportunities sit in stages the stage mapping does not cover, the setup rejects the selection and names the stages.

A convincing selection contains deals the sponsor of the proof of concept at your company recognises, for example a region with familiar numbers. It contains enough history for a trend, not just one quarter.

What your team settles beforehand

The cycle length is stated in quarters. It comes from the people who run the deals, because it determines the window of the evaluation. If the cycle varies by segment, the predominant one applies.

The cycle length produces two models of that length, PERFORM and BUILD. What separates the two models is described in the whitepaper BUILD and PERFORM compared.

Targets for the period shown belong on the list as well. Without targets, the proof of concept shows pipeline but no performance against plan.

Whoever sets up the proof of concept is an administrator or analyst and is assigned a permission set group for it. Everyone who starts a run or the connection test needs the same group. End users see nothing new.

What is created in your production org

During the sandbox phase, no package is installed in the production org and nothing is written. The package is installed in the sandbox only.

During the sandbox phase, your administrator creates exactly two things in the production org.

1. An integration user with read permissions, following the principle of least privilege and without user-interface access.
2. An External Client App with the client credentials flow that runs as this user.

Nothing else is created there: no metadata, no fields, no automation.

During the sandbox phase, exactly two things are created in your production org: an integration user with read permissions and an External Client App. You deactivate both at the end.

The limitation to the sandbox phase is deliberate. After a migration into production, production behaves like any installation; the chapter on migration describes it.

Which data go where

The sandbox drives the run. It goes through the selected opportunities and asks the production org for their history through the Salesforce REST API.

The history stays in your Salesforce environment: it goes from the production org into a sandbox of the same company. In doing so the history leaves the production org, and the production org is only read.

This sentence applies to the history on its way from production into the sandbox. It does not apply to AI commentary or to Strategist. Each of those has a data path of its own, and the next chapter describes it.

If an opportunity is missing from the copy, its rows are skipped and counted; the summary of the run states the number. An incomplete copy therefore leads to a smaller result, not a silent one.

Strategist and AI commentary in the sandbox

The proof of concept is not a special case. It is the construction of the product in a sandbox, with the same commitments and the same limits.

AI commentary in Core

Funnel Economics Core calculates in the Salesforce org it is installed in; in the proof of concept, that is your sandbox. For dashboard commentary, Core can call a language model. This AI data transfer is off by default and is enabled per org and per user; the package masks personal values before the call.

In your sandbox, enabling the AI data transfer is a decision of the people responsible for data protection at your company, not of the proof of concept.

Funnel Economics Strategist

Funnel Economics Strategist is an optional add-on. The prepared context passes through a service we operate to your chosen language model.

If you use Strategist in the proof of concept, it is connected to the sandbox. Strategist's Salesforce access is read-only.

Rep names, opportunity names and record links go along by design: an answer with placeholders would be useless. Strategist does not mask or pseudonymise them. This is a decision, not a gap. The same decision applies to the proof of concept as to any installation.

Agreements and controls

Our leg requires a data-processing agreement, which we are preparing. The language model processes the data under your own agreement with the provider.

There we strongly recommend an enterprise agreement with a data-processing agreement that excludes training use; a recommendation, not a precondition. The exclusion has to come from your agreement with your provider.

Strategist requires a per-user authorisation that your Salesforce administrator controls and can revoke.

The controls are the org-level opt-in and the per-user permission; the server-side check of that permission is built and becomes effective with the package endpoint it needs.

The package's AI switch and permission set do not stop Strategist yet — the server-side check is built but not in force.

Both data paths and their controls are described in the whitepaper Trust Boundary for AI on Salesforce Data. The short version for the approval is on the page AI Data Privacy: What Leaves Your Salesforce Org.

Migrating into production is your decision

Within the six-month engagement you can migrate into your Salesforce production org. That decision is yours.

Technically, the migration is possible before the AppExchange security review. The migration does not depend on the review: whether you migrate without a passed review is for you to decide.

After the migration, production behaves like any installation. Core writes only its own package objects, never standard objects such as Opportunities.

You take decisions along, not data

The proof of concept is not a migration tool, and it does not become the installation. Production is installed afresh, and the history then comes from the org itself. No connection remains to be maintained.

You take five decisions along: the Opportunity Type, the cycle length, the stage mapping, the SLAs and the region structure. Write the decisions down at the end of the proof of concept, while the reasoning is fresh.

Where the review stands

The AppExchange security review is planned after the beta phase. No date and no commitment follow from that, and a migration does not require the review.

Three failure patterns to know beforehand

The first failure pattern has a cause in Salesforce itself. The access of the External Client App depends on a permission set and cannot come from a profile.

The second failure pattern is the most costly, because it looks like a data finding. The field history is not rejected but hidden: fewer rows arrive, and no error message. Whoever sees a conspicuously thin history checks the read permissions first and the data only afterwards.

How the proof of concept ends

A proof of concept has an end. Letting it run on silently is the worst variant: the sandbox drifts, and the connection breaks at the next refresh.

• On success, production is installed afresh, and you write the decisions down. You deactivate the two things from the sandbox phase in that case as well.
• Without success, you deactivate the two things created in the production org. Nothing else was created there.
• In either case, the evaluation is switched off in a sandbox that stays. That way no run starts against a connection nobody watches.

What has to be undone at the end is exactly the two things in the production org: deactivate the External Client App, deactivate the integration user. Nothing has to be undone in the sandbox.

All data paths, the controls and their status are set out on the Security & Trust page. Which questions the evaluation answers in day-to-day work is described on the page Sales Pipeline Metrics for RevOps: One Number per Stage. For anything beyond them, ask us directly.