Two buttons sit quietly on every record in Dynamics 365, and between them they answer the question that security roles alone cannot: who works on this specific record, and who else gets to see it? Security roles define what a person can do with a whole table. Assign and Share operate one record at a time — and knowing when to reach for each is a small skill that pays off daily.
Assign: changing the owner
Almost every record has an Owner — the user or team whose record it is. Ownership matters because most security roles are written in terms of it: a salesperson can typically edit their own accounts, a manager can edit their business unit’s, and so on. Assign is how ownership moves.
The dialog offers “Me” as a shortcut or a lookup for any user or team. Assigning to a team is the underused option: a record owned by the Support Tier 2 team is editable by whoever is on that team, this week or next, with no re-assignment when people rotate. That is usually the right model for shared work, while personal ownership fits carried quotas and personal pipelines. Assignment is also what routing does automatically — the manual button and the automated rules move the same lever.
Share: access without ownership
Sometimes the owner should stay the owner, but one more person needs in. A finance colleague reviewing one contested account, a specialist consulting on one gnarly case. That is Share — under the Share menu, choose Manage access:
Pick a user or team, and grant exactly the permissions this situation needs: Read, Write, Delete, Append, Append to, Assign, Share. The checkboxes are the whole point — sharing is not all-or-nothing. Read-only for the reviewer; Read and Write for the collaborator; almost never Delete or the ability to re-Share, which lets access sprawl beyond your sight. The share applies to this record only, and it survives until someone removes it — which is also the discipline: shares accumulate silently, so treat them as exceptions and prune them when the situation ends.
Choosing between them
My rule of thumb: Assign moves responsibility, Share extends visibility. If the question is “whose job is this record now?”, assign it (to a person for accountability, to a team for shared pools). If the question is “can this one extra person see or touch it, without changing whose it is?”, share it, minimally. If you find yourself sharing the same set of records with the same people over and over, that is not a sharing problem — it is a security-role or team-structure problem, and fixing it at that level beats a thousand shares. The related Check Access command (on the record’s overflow menu) closes the loop: it tells you exactly why any given user can or cannot see the record — ownership, role, or a share — which turns “why can’t Sara see this?” from a support ticket into a ten-second lookup.
Small buttons, big model: roles set the boundaries, ownership does the day-to-day, sharing handles the exceptions. Keep each one doing its own job and record security stays legible.
