People with operate access can be assigned tasks

16 October 2026 — When an accounting firm works on its client's tax ID with operate access (see granted access), its people can now be assigned tasks in that company. Until today only the members of the company could, so a key of the firm could not assign work to its own team in the client's tasks.

Three operations change what they return or accept. No field, scope or error code is added.

• The user list includes them. GET /v1/companies/{company}/users returns the members of the company and, in addition, the people of other accounts that reach it with operate access through an account relation. People with view access are not listed.
• The current user too. GET /v1/companies/{company}/users/me answers for a person of another account when the key belongs to one with operate access to the company. If the key holder is neither a member nor such a person, it still returns 404 route_not_found.
• Assigning accepts them. POST /v1/companies/{company}/tasks/{task}/assign now takes the assignee_id of any of those people. Anyone else, including a person with view access or one from an unrelated company, still gets 422 task_assignee_not_member.

The response keeps exactly the same shape. We do not say which account a person comes from: you get the same id, name, email, initials and avatar color as for a member.

If the access ends or drops to view, we unassign that person from the open tasks of the company, so you will see assignee_id become null on them. Completed tasks keep who did them.

If your integration builds an assignee picker from GET /v1/companies/{company}/users, you do not have to change anything: the new people simply appear in the list. If it assumed that everyone in that list is a member of the company, review that assumption. See Tasks for the full flow.

Updated operations

No operation, field or scope is added.

KeyRound

Granted access between accounts

ListTodo

Tasks