What your IT team should ask before an agent gets write access

A list you can forward to the person who can veto the project: the permission set, where the model call goes, what is in the log, and what we cannot answer without seeing the tenant.

Forward this to whoever owns access in your business. They are not being difficult. They are the reason a pilot that ran as an administrator cannot be promoted.

We put a supervised agent on one workflow, inside the systems you already run. A person still signs the writes that can hurt you. That design only holds if the integration user is narrower than a human login, and if someone in IT has seen the permission set before go-live rather than the night before.

The permission set we ask for, and the ones we refuse

In Salesforce the integration user or connected app should run queries and data changes in user mode, so object permissions and field-level security actually apply. Salesforce’s own guidance for agent actions now points at that, and at scoping each action to the minimum it needs. That guidance is right. It is also why demos break when they are rebuilt properly.

What we ask for, in writing:

  • Read on the objects the workflow has to see. Tickets, leads, invoices, the related account or organisation record. Not the whole org.
  • Write on a closed list of fields. Routing, tags, proposal fields, an internal note. Canonical forecast fields stay behind a deterministic gate unless you explicitly add them later.
  • No delete. No modify-all. No manage users. No export of the whole object.

What we refuse, even if it would make the first week easier:

  • Using a named administrator’s credentials “just for the pilot”.
  • Modify All Data, View All Data, or a profile copied from a sysadmin.
  • Permission to send email to a customer, post a public comment, or change a payment fact, until those writes have their own review.

The same shape shows up in a helpdesk with different words. An admin token that can merge tickets and read every organisation is fine for a builder and wrong for a service account. We treat the permission set as a deliverable. What the agent cannot do is the more useful document.

Where the model call goes

IT will ask whether customer data leaves the tenant. Answer it without theatre.

The agent reads records through your API, under the integration user. The model call is a separate hop. We will tell you which provider we are using for that workflow, which region the call is configured for, and what of the record is in the prompt. A ticket subject and a policy snippet is a different conversation from pasting the whole account history.

A SOC-style badge on a vendor website does not replace a subprocessor list with regions. Ask for the list. Ask which subprocessors see the prompt. Ask what is retained, for how long, and whether you can turn retention off. If a vendor cannot name the region, they are not ready for your review.

We would rather lose a week answering this than discover it in a security questionnaire after the build has started.

What has to be in the log

If something wrong is written, someone will ask who did it, with what input, and who could have stopped it.

The log for a live agent should hold, at minimum: the record identifier, the event that triggered the run, the fields read, the action proposed, whether a person approved it, the fields written, and the time. Keep it in a place your own team can query. A vendor dashboard you can only screenshot is not a log.

Retention is your policy, not ours. We will say what we can keep and for how long. We will not invent a legal obligation you may not have. If you are in a regulated process, bring that to the assessment.

What we cannot answer without seeing the tenant

Three things, and they are the reason the first step is a look at the real process rather than a paper architecture.

Which of your existing triggers, flows, and automations already write the same fields. Two writers on one priority field will fight, and the fight looks like a broken agent.

Which custom fields use internal identifiers rather than the labels people see. An agent that writes a plausible label into a restricted picklist either fails or writes a value your reports do not recognise.

Whether the sandbox you want us to use still matches production. A sandbox is a point-in-time snapshot. Permissions, record types, and the ugly tail of the data are usually the parts that drifted.

Those answers need a login, a sample of real items, and the person who owns access on the call. The assessment is free. If the write path cannot be scoped, we will say so in 30 minutes, and you keep that finding.