1. Why this document exists

On our call you asked two questions I could not answer on the spot:

1. How hard is this to integrate with Salesforce?
2. How hard is it to pilot — given that Mike, Ronnie, and everyone else are consumed by the Aspire bridge through the September 1 go-live?

This document answers both. It also isolates the one thing I genuinely need from you before I can quote effort, timeline, or cost.

The short version: there is a version of this pilot that requires zero work from Mike and zero contact with your production Salesforce org. That is my recommendation for the next 30 days. Everything past that can wait until Aspire is stable.

2. What we are actually building

Worth stating plainly, because the demo covered more ground than the product needs to.

Not in scope: dashboards, pipeline reporting, forecast views, rollup analytics. You have built those yourself, you build them well, and you build a new one every time you hire someone. Rebuilding them would be me selling you something you already own.

In scope — the outreach engine. In your words on the call:

"…where it's looking back at what should be contacted today, this week, based on the data that it sees. And it's also having cadences of: hey, this much time's gone by, you haven't communicated. We submitted a bid 30 days ago. Here's the email you need to send them right now."

Concretely, that decomposes into four functions:

Plus one adjacent capability you flagged as valuable: job-change detection — when a known contact at a customer moves to a non-customer, flag it with a drafted reach-out. You do this manually in Sales Navigator today.

The design principle, which is also the business case: let the sales guys sell. The measurable outcome is engagement volume per rep, not another screen.

3. What the tool needs from Salesforce

3.1 Read access

All of it is standard-object data. No custom development on your side.

Plus any custom fields on Account or Opportunity that carry service line, contract type, branch, or the Aspire linkage. I will not know what those are until I see the schema — that is one of the first things I would pull.

3.2 Write access — Phase 2, not the pilot

You asked whether the tool could push a corrected close date back into Salesforce when a deal goes overdue. Yes, and it is a small amount of work. But I would deliberately not turn it on for the pilot. Write-back to a production CRM is the part that creates risk and the part that will make Mike nervous, and it earns nothing that the pilot needs to prove.

When we do enable it, the write surface stays deliberately narrow:

• Task — insert only (log the outreach that was sent)
• Opportunity.CloseDate — update, with an audit trail
• Opportunity.NextStep — update
• One custom field, Last_Assisted_Touch__c — so you can always tell which activity came from the tool versus a human

Every write is logged with actor, timestamp, prior value, and new value. Nothing is deleted, ever.

3.3 One thing I need to check early

The "gone quiet" and "no communication in X days" logic is only as good as your activity data. If reps consistently log calls and emails against the record — or if Salesforce Inbox / Einstein Activity Capture is auto-logging — then LastActivityDate is trustworthy and the signals will be sharp.

If activity logging is inconsistent, the tool will confidently tell a rep an account has gone quiet when the rep spoke to them last Tuesday. That destroys trust in the tool in about a week.

This is a five-minute check against real data, and it is genuinely the single largest determinant of whether the pilot feels smart or feels broken. It is also solvable — the fallback is to derive recency from email sync rather than logged activities — but I need to know which world we are in before I build the ranking logic.

4. Environment options

Four ways to do this, in increasing order of effort and of demand on your team.

Option A — Data extract, no org access (recommended for the pilot)

You run a report in Salesforce and export CSVs. I load them into the tool. That is the entire integration.

• Salesforce admin effort: none. Mike is not involved and does not need to be told.
• Your effort: roughly 20–30 minutes, once. Five or six report exports.
• Production risk: zero. Export is a read. Nothing is installed, no credentials are issued, no connected app exists, nothing writes anywhere.
• What it proves: everything that matters — whether the signals are correct on your real book of business, whether the ranking is sensible, whether the drafted emails are good enough that a rep would actually send them.
• What it does not do: refresh on its own. It is a point-in-time snapshot. Sending is manual (draft → your clipboard/Outlook) rather than in-app.

This is the option I want. It sidesteps the September 1 constraint entirely, and the questions the pilot needs to answer do not require live sync. If the drafted emails are not good enough, live sync would not have saved them.

Option B — Developer sandbox + read-only API

A real integration, running against a sandbox rather than production.

• Salesforce admin effort: roughly 1–2 hours total.
• Production risk: very low. See §6 for why creating a sandbox does not touch your production org — this is the part worth reading before you decide anything.
• Timing: feasible before September 1 if you want it, but I would not push for it.

A Developer sandbox copies your configuration and metadata but no records. So it would need seeding with a data subset — which is the extra step that makes this meaningfully more work than Option A, not the sandbox creation itself. A Partial Copy sandbox brings a sample of real data and skips the seeding, but refreshes on a 5-day cycle and consumes a license your edition may only include one of. Mike will know which sandboxes are already spoken for.

Scoping the subset to a single rep's book — yours or Robby's — keeps the seeding small.

Option C — Production, read-only integration user (post go-live)

The steady state for a real deployment. Read-only, scoped by permission set, nightly sync.

• Timing: after Aspire is stable. Not before.

Option D — Production, bidirectional

Full write-back per §3.2. Only after Option C has run clean for a while.

Recommendation

Run Option A in August. Decide between B and C in September, after go-live.

The pilot answers "are the signals right and are the emails good?" Option A answers that for a fraction of the effort, and it removes the one objection you raised on the call — that anything touching the sandbox right now lands on a team already under pressure.

5. Access mechanics — for Mike, when we get there

Nothing in this section is needed for Option A. It is here so that when Option B or C comes up, you can forward this section and Mike has the whole picture in one pass.

Authentication. A Connected App using the OAuth 2.0 JWT bearer flow — server-to-server, certificate-based, no stored password, no interactive login. Client credentials flow is the alternative if that is the house standard.

Identity. A dedicated integration user, not a human's account. Salesforce includes a small number of free Salesforce Integration licenses on Enterprise and above; if none are available, a standard license works.

Permissions. One purpose-built permission set granting: - Read on the objects in §3.1, and nothing else - No "Modify All Data," no "View All Data," no admin profile - API Enabled - Write permissions added only at Phase 2, scoped to the four fields in §3.2

Connectivity. IP allowlisting on the connected app if you prefer to restrict by origin — I can supply a static egress IP.

API load. Initial pull via Bulk API 2.0, then incremental syncs on LastModifiedDate. Expected steady-state consumption is in the low thousands of calls per day against a daily allowance that runs into the hundreds of thousands. This will not be visible in your API usage.

6. Why none of this endangers the Aspire work

This is the section that matters most for your internal conversation, so I want to be precise rather than reassuring.

Creating a sandbox does not modify production. A sandbox copy is a read operation against your production metadata. It creates a separate org with its own URL, its own data, and its own limits. Nothing about the production org, its records, its integrations, or the Mind Cloud bridge changes as a result. Production cannot be affected by anything that happens inside a sandbox afterward.

Two real caveats, both worth naming:

1. A new sandbox inherits your integration metadata. The connected apps, named credentials, remote site settings, and any flows or Apex belonging to the Mind Cloud bridge get copied into the sandbox along with everything else. If any of those carry hardcoded production endpoints, a freshly created sandbox can attempt to call Aspire. This is a known and standard post-refresh step — the endpoints get pointed at nothing, or the integration user gets deactivated in the sandbox — but it must be done deliberately, and it is exactly the kind of thing that gets missed when the team is busy. This is the strongest argument for Option A right now.

2. Sandbox creation consumes a sandbox license and Mike's attention. Small, but not zero, and attention is the scarce resource this month.

Option A has neither caveat. A report export touches nothing.

7. Data handling

• Data is stored in an isolated database with row-level security; access requires an authenticated session against an explicit allowlist.
• Access is role-scoped — your view rolls up across reps, a rep sees their own book.
• Full audit log on every edit and every send.
• No customer data is used to train any model. Draft generation sends the specific account context needed for that one email and retains nothing.
• Extract data is deleted at your request, and automatically at the end of the pilot if it does not proceed.
• Emails send from your own domain through your existing infrastructure, not through a third-party sending service — deliverability and reputation stay yours.

8. What I need from you — the 30-minute session

I cannot quote effort, timeline, or cost until these are settled. These are the questions; none require preparation.

9. Proposed next steps

Effort and cost for the production integration get quoted after step 2, once the answers in §8 are known. Quoting before that would be a guess, and it would be wrong.

Appendix A — Option A export list

Six reports. Standard Salesforce report builder, exported as CSV. No filters beyond what is noted; more data is better than less.

1. Accounts — all fields in §3.1
2. Contacts — all, with AccountId
3. Opportunities — all, open and closed, last 24 months
4. Opportunity Contact Roles
5. Activities (Tasks and Events) — last 12 months
6. Users — active users only

If any report is awkward to build, send what comes easily and I will work from that. I would rather start with four imperfect exports than wait for six perfect ones.

Appendix B — Terms