Start with a resettable simulation workspace.
The first evaluation path should not depend on real tenant credentials or founder narration. ActionPlane now starts with a separate Salesforce simulation workspace per user, seeded with meaningful records, approvals, evidence, failures, and rollback context.
A validated Salesforce connector profile with metadata ready.
Stable Opportunity, Account, and Contact records.
One pending approval, one completed run, and one failed run.
Artifacts, audit history, rollback context, and observability on the same story.
Reset returns the workspace to the exact baseline.
Salesforce CRM
Use the seeded Salesforce simulation workspace to show the full ActionPlane story without real tenant credentials, then connect a real developer org when the team is ready.
Sandbox availability
Keep the first connector setup constrained to one environment, one identity, and one clearly reviewable workflow.
Open the simulation workspace first
Start in the built-in Salesforce simulation workspace so the developer and buyer can both see the same seeded Opportunity story before any real credentials are involved.
Create a Salesforce developer org
Use the official Salesforce developer signup, then create a dedicated sandbox or developer org user for the first ActionPlane workflow.
Create the integration app and gather credentials
Create a Salesforce External Client App or Connected App, grant only the minimum scopes needed, and collect the login URL, client ID, and client secret.
Enter the connector settings in ActionPlane
Open the Salesforce connector page in ActionPlane and enter the login URL, client ID, client secret, API version, and the initial Opportunity allowlist for StageName, CloseDate, Amount, and NextStep.
Validate auth, sync metadata, and run the first dry run
Validate auth, sync Opportunity metadata, and then submit the canonical Northwind opportunity sample as a dry run before allowing a single live sandbox write.
Business context
RevOps wants to move the Northwind renewal from qualification into proposal after pricing review.
Starting record state
Opportunity `Northwind renewal FY26` is in `Qualification` with `Amount=120000`, `CloseDate=2026-05-20`, and `NextStep=Confirm pricing committee review`.
Requested change
Move the opportunity to `Proposal / Price Quote`, raise the amount to `148000`, push the close date by one week, and update the next step.
Why it routes
The amount and stage shift affect revenue posture, so the sample shows the approval lane first and a separate completed execution with rollback context already attached.
Expected artifacts
Request evidence, preview, rollback plan, completed output, rollback execution, and immutable audit events all stay attached to the same run.
Reset behavior
Reset returns the simulation workspace to the exact seeded Northwind record state and restores the sample evidence baseline.
Onboarding metering tracks activation progress for the connector. It is not a separate billable unit; workspace billing remains governed-run based.
Save the connector, validate it immediately, and sync metadata in one authenticated call.
{
"loginUrl": "https://login.salesforce.com",
"clientId": "\u003Cclient-id\u003E",
"clientSecret": "\u003Cclient-secret\u003E",
"refreshToken": "\u003Crefresh-token-or-empty\u003E",
"apiVersion": "66.0",
"isSandbox": true,
"isEnabled": true,
"validateAfterSave": true,
"syncMetadataAfterSave": true,
"managedObjects": [
{
"objectApiName": "Opportunity",
"displayName": "Opportunity",
"allowedFields": [
"StageName",
"CloseDate",
"Amount",
"NextStep"
]
}
]
}
curl -X POST \ "$ACTIONPLANE_BASE_URL/api/connectors/onboarding/salesforce-crm/connect" \ -H "Authorization: Bearer <session-token>" \ -H "Content-Type: application/json" \ --data @"connect-salesforce-crm.json"
Re-run auth and instance validation without resubmitting the connector payload.
curl -X POST \ "$ACTIONPLANE_BASE_URL/api/connectors/onboarding/salesforce-crm/validate" \ -H "Authorization: Bearer <session-token>" \ -H "Content-Type: application/json"
Refresh the writable object and field catalog after credentials or allowlists change.
curl -X POST \ "$ACTIONPLANE_BASE_URL/api/connectors/onboarding/salesforce-crm/sync-metadata" \ -H "Authorization: Bearer <session-token>" \ -H "Content-Type: application/json"
Scenario-backed Salesforce simulation workspace with seeded records and reset support
Opportunity preview, approval, simulated execution, rollback, and evidence on the same run
Live sandbox path through server-to-server Salesforce auth when you bring your own developer org
First-class onboarding API can save, validate, and sync the connector in one authenticated flow
Use the simulation workspace first, then repeat the same Northwind-style scenario in a real Salesforce developer org.
Validate auth, metadata, one dry run, one live sandbox write, and one rollback before widening field coverage.
Keep production off until the same preview and rollback evidence quality holds in your real sandbox.
The built-in simulation is only seeded for the first Salesforce CRM story today.
The first live Salesforce workflow is still limited to Opportunity fields `StageName`, `CloseDate`, `Amount`, and `NextStep`.
Other connector simulations are documented but not yet seeded as first-class workspaces.
Free developer environments exist for a few connectors even before full simulation.
Salesforce CRM, ServiceNow ticketing, and HubSpot CRM have official free developer paths.
Zendesk, Freshdesk, and Intercom start with vendor trials instead of official free developer accounts.
ERP, finance, and HCM lanes still require a customer-owned sandbox because the proof must mirror your real control points.
A first demo should not depend on hidden credentials or hand-waving.
No paid account is required for the first evaluation path.
The buyer and the technical evaluator can both inspect the same sample story.
Reset makes repeated demos predictable instead of drifting over time.