What Happens to Saved Views When You Redesign Security Roles

Users do not experience a security redesign as a cleaner permission model. They experience it as the morning their screen changed and their saved views were gone. In Dynamics 365, personalizations are published to roles, so when you replace a user's roles, their personalizations do not come along unless you carry them deliberately.

The link nobody sees until it breaks

A saved view, a tuned grid layout, a reordered set of columns, a filter someone set up once and has relied on every day since, these are personalizations. In D365 a published personalization is associated with a security role. The configuration that stores it is tied to the role the user holds, not to the user as a free-floating identity.

That link is invisible during normal operation. The user opens a form, their view loads, and nobody thinks about why. It only becomes visible at the one moment it is most painful: when the role underneath the personalization goes away.

Why a redesign threatens it

A role redesign does exactly the thing that severs the link. You build a new, cleaner set of roles, often named as a V2 generation, and you assign users to them in place of their old roles. Then you revoke the old roles.

From a least-privilege standpoint that is the whole point. From the user's standpoint, the role their published views were attached to has just been taken away. The new V2 role is a different object. The personalizations do not follow it automatically, because nothing about creating a new role copies the old role's published views onto it. At cutover, the user signs in to the redesigned world and the views are simply not there.

Nothing errored. The redesign worked. The access model is better. And the user is furious, because the thing they actually touch every day got quietly worse.

This is an adoption risk, not a technical footnote

A security rollout rarely dies on the technical merits. It dies on adoption. The constituency that kills it is the end-user population, and the complaint is almost never "my permissions are wrong." It is "my screen changed and my views are gone."

That complaint lands hard because it is concrete, it is personal, and it hits people who had no stake in the redesign and no warning. One well-liked power user losing their carefully built views can generate more resistance than any permission change, because everyone around them hears about it. Permissions are abstract. A lost daily view is not.

So preserving personalizations is not housekeeping you get to later. It is part of whether the rollout survives contact with the people living in the system.

Carrying personalizations is a deliberate step

The fix is to treat personalization migration as its own planned step in the cutover, with the same seriousness as assigning the new roles and revoking the old ones.

That means, before cutover:

• - Inventory what personalizations exist and which roles they are published to, so you know the scope. A client's population can hold a large number of saved views spread across many roles, and you cannot carry what you have not catalogued.
• - Map each personalization from the old role it lives on to the corresponding new V2 role that should carry it.
• - Republish the personalizations onto the new roles as an explicit migration action, verified before the old roles are revoked, not discovered afterward.

In a mature redesign pipeline this shows up as a dedicated republish step that runs after the new roles are built and assigned and produces an auditable list of which personalizations were carried onto which V2 roles. The important part is not the tooling. It is that somebody decided personalizations are an output of the migration, planned for it, and checked it, rather than assuming the views would take care of themselves.

Bottom line

Personalizations in D365 are published to roles, so replacing a user's roles orphans their saved views unless you carry them across on purpose. Treat personalization migration as a named step in the cutover plan, inventory and map and republish before you revoke, and you keep the one part of the system users notice. Skip it, and a technically perfect redesign still fails the only test that matters, which is whether people keep using it.

Frequently asked questions