The lead process rebuild depends on automation writing to records under its own name rather than under a person's. That needed a separate identity with a narrow role, and a test of whether the platform will let such an identity do the work. It will do most of it.
- The automation now signs in as itself, with a role built for the job rather than as an administrator. It can read leads and it can create, read, update and assign tasks and emails. Proving the role really is narrow meant asking it to read something outside that role and having the platform refuse, which is stronger evidence than reading the role back, because the refusal comes from the system rather than from the person who built it. One thing worth knowing for anyone doing the same: a new role reads back holding more than it was granted, because the platform seeds every role with a set of its own, so the only honest way to state what a role allows is to read the role and not the grant.
- Whether the connection really was the automation rather than the person could not be established from any configuration screen. The name, the owner and the status all look identical either way. The only evidence available anywhere is a record showing who last changed it, so the test was to have the automation write to a disposable record and read the name back off it. It came back as the automation.
- The automation can run the reconciliation on a schedule but cannot start it the moment a record changes. Two flows identical in every respect except which identity they used settled that: the one on a person's connection fired immediately, the one on the automation's never fired at all. The plan now reconciles every fifteen minutes rather than within seconds, which keeps the record of who changed what that the separate identity exists to provide.