Customer Attribution now lets workspace admins assign shared-service requests to the customer account they belong to. Requests made through a common application key can appear in that customer’s usage and history, alongside work made through the customer’s own keys.
The rules use identifiers already present in request tags. A rule selects the source keys, matches a tag template containing an account ID, and looks up that ID among known customers. For example, a template such as account-{id} can resolve a tagged account even when the request used a shared service key. The lookup requires a known customer; an unfamiliar ID does not create an account.
Open Settings → Data Rules → Customer Attribution to test a request and preview a saved draft. Workspace members can inspect and test rules; workspace admins can edit and activate them. Preview dates limit the preview. Activation applies the saved rules to retained matching requests, and later syncs keep the active rules applied to new data.
The original serving key remains visible in the request evidence. Competing customer matches stay available for review rather than being assigned arbitrarily. Customer-owned credentials require an explicit override before a rule can move their requests.
Attributed shared-service calls count as machine activity. Knowing the account does not establish which human interaction caused a call, so attribution does not turn copied customer text inside an automated request into a human message.
Published rule revisions can be replayed, and an earlier revision can be restored. An admin can revisit the attribution as the application’s tagging changes.
Development record: November 3–4, 2026. Written retrospectively on November 6, 2026.