Security & access management

Security work is where you discover that Dataverse is not “broken”—it’s just extremely literal. These tools help you manage access at scale and troubleshoot the classic:

“Why can’t they see X?”

Pick your weapon (quick decision guide)

• Need: Manage a user’s roles/teams efficiently (especially when you’re doing the same setup for 30 people)
  Tool: User Security Manager
  Why: Fast onboarding + quick comparisons without 900 clicks

• Need: Bulk assign users to Teams and BUs from a CSV list (great for onboarding waves)
  Tool: Bulk Security Patcher
  Why: Repeatable bulk onboarding with safer piloting and spot checks

• Need: Compare roles + privileges to diagnose permission gaps quickly
  Tool: Security Role Compare Tool (DotCy Toolbox)
  Why: Fastest route to the exact missing privilege (often Append / Append To)

Pre-flight checklist (avoid false conclusions)

• ✅ Identify exactly what’s failing: read? create? append? append-to? assign?
• ✅ Identify the target: table-level access vs record-level access (ownership/sharing)
• ✅ Confirm Business Unit structure and team membership
• ✅ Remember: Admin view ≠ user view

Consultant law #5: If you don’t know the privilege required, you are debugging security by astrology.

Tool 1: User Security Manager

(roles/teams at scale)

What it’s for

Efficiently managing a user’s security—roles and teams—without clicking through the UI 900 times.

When to use it

Use it when:

• You’re onboarding users and need consistent role assignments
• You’re troubleshooting “works for one user but not another”
• You need to quickly review a user’s roles/teams

Step-by-step (onboarding pattern)

1. Find a “golden user” who has correct access.
2. Compare the new user against the golden user:
   • roles
   • teams
   • business unit
3. Apply the minimum necessary changes.
4. Have the user retest the exact scenario.

Common gotchas

• Users are in the right role but wrong Business Unit.
• Team membership grants access indirectly (easy to miss).
• Access Teams / sharing / owner changes create “it works for me” confusion.

Validation checklist

• User can complete the exact failing action.
• You did not grant broad access “just to make it work.”

Tool 2: Bulk Security Patcher

(bulk assign users to Team and BU from CSV)

What it’s for

Bulk assignment workflows—especially helpful for org-wide onboarding, role migrations, or restructuring.

When to use it

Use it when:

• You have many users to assign to teams/BUs
• You need repeatable onboarding steps
• You’re standardizing access by department

Step-by-step (safe bulk change workflow)

1. Prepare CSV with validated email addresses.
2. Do a tiny pilot (5 users).
3. Apply at scale once pilot is confirmed.
4. Post-run spot check:
   • random 5 users
   • one user from each business unit

Common gotchas

• One typo in email becomes one “why am I missing?” ticket.
• BU changes can have cascading access implications.
• Some access comes from multiple teams—bulk patching can unintentionally remove or override your intended model depending on how you use it.

Validation checklist

• Pilot group passes scenario tests.
• Full group receives intended roles/teams.
• No “everyone is System Admin now” incidents occurred ✅

Tool 3: Security Role Compare Tool (DotCy Toolbox)

(why can’t they see X?)

What it’s for

Comparing roles and privileges to pinpoint differences.

When to use it

Use it when:

• Two users “should” have the same access but don’t
• You need to confirm least-privilege deltas between roles
• You’re refactoring roles and want to avoid regressions

Step-by-step (permission gap diagnosis)

1. Compare “User Role” vs “Expected Role”.
2. Look for missing privileges:
   • Read/Create/Write/Delete
   • Append/Append To (the most common “but it should work!” culprit)
3. Update role(s) intentionally.
4. Retest scenario as user.

Common gotchas

• Append/Append To issues masquerade as “lookup not saving”.
• Privilege depth (User/BU/Parent-Child/Org) matters more than people think.

Validation checklist

• After role update: user can perform the action without over-privileging.
• Changes are documented and promoted properly through environments.

“Break glass” admin steps (use sparingly)

When you truly must unblock:

1. Grant elevated access temporarily (document who/why/when).
2. Fix the root role/team model.
3. Remove elevated access.
4. Confirm least-privilege is restored.

(This is the security equivalent of using duct tape on a plane: it works, but you don’t brag about it.)