Governing Salesforce Agentforce: authority and proof for CRM agents

Agentforce puts AI agents to work inside the CRM: lead qualification, customer replies, sales follow-ups, case summaries. These agents operate in direct contact with the company's most regulated data — contact details, purchase histories, conversations — and their most useful actions are precisely the outbound ones: sending an email, sharing a record, syncing to another tool.

Platform controls frame the model and access to CRM objects. What they cannot know is the law that applies to the action: did this prospect consent to being contacted? Does exporting this segment to a marketing tool hosted elsewhere trigger a transfer obligation? Those questions depend on your jurisdictions and your profile — not on the platform.

The integration scenario

The principle: wherever your Salesforce flow can make an outbound HTTP call — an external action in a flow, a service the agent calls before its send step — you insert the decision BEFORE the action. The authority layer is a network call, not a package to install in your org.

1. 1

   Generate your organization's profile

   The free assessment (start here) produces your policy profile: your customers' jurisdictions, your sector, the data categories your CRM processes. That profile personalizes every decision.

2. 2

   Create an API key with the authority scope

   From your StructureClerk dashboard. Personalized decisions go through the key; verifying evidence stays public.

3. 3

   Insert the call before the outbound action

   In the flow that precedes the email send, segment export or sync, call the decision endpoint with the action's metadata — never the message content or the customer data itself.

   curl -X POST https://structureclerk.ca/api/v1/authority/decide \
     -H 'Authorization: Bearer $API_KEY' \
     -H 'Content-Type: application/json' \
     -d '{"agent":{"id":"agentforce-sdr","autonomy_level":3},"action":{"type":"send.customer_email","data_categories":["personal"]},"context":{"jurisdictions":["CA_QC","FR"],"sector":"tech"}}'

4. 4

   Wire the four verbs to your flows

   ALLOW lets the send go out. APPROVE creates a human approval task. DENY stops the flow and logs the reason on the record. ESCALATE notifies compliance. The evidence identifier attaches to the CRM record: the audit lives in the customer file.

The decision contract

POST https://structureclerk.ca/api/v1/authority/decide
{
  "agent": { "id": "agentforce-sdr", "autonomy_level": 3 },
  "action": {
    "type": "send.customer_email",
    "data_categories": ["personal"]
  },
  "context": { "jurisdictions": ["CA_QC", "FR"], "sector": "tech" }
}
// →
{
  "decision": "APPROVE",
  "reason": "external_personal_data_transfer",
  "confidence": 0.95,
  "evidence_id": "ev_2b71…e04a"
}

The decision is advisory — StructureClerk decides, your infrastructure enforces. The engine never sees the email content or the customer records: only the action type, data categories and jurisdictional context.

An audit trail your customers can verify

Every decision leaves Ed25519-signed, chained evidence. When an enterprise customer asks how your CRM agents respect consent and transfer rules, you hand over evidence they verify themselves on our verification page — no account, no depending on your word.

Because the engine is jurisdictional, the same campaign can receive two answers: the send to customers in one jurisdiction passes, the same send to another requires validation — because the recipient's law changes the decision. That is what no internal platform rule models.