Security That Doesn’t Ruin Everyone’s Day

TL;DR

Most security issues are one of these:

• Ownership (who owns the record)
• Scope (user vs BU vs org)
• Sharing (teams/access teams)
• Append / Append To (the sneaky one)
• Field security (field is hidden, record isn’t)

If you treat it like a mystery novel, it takes forever.
If you treat it like a checklist, it’s quick.

Jump menu

• You’re here because… (symptoms)
• Fast path: diagnose in 10 minutes
• Plain-English mental model
• Decision tree: missing record vs can’t edit vs can’t relate
• Append vs Append To (finally explained)
• Recommended approach: personas → roles → teams
• Common gotchas
• Definition of Done
• Printable checklist + templates

You’re here because… (symptoms)

Pick your pain:

• “I can see it as admin but users can’t.”
• “They can open the record but can’t edit/save.”
• “They can’t create related records (notes, activities, connections).”
• “They can’t set a lookup / relate records.”
• “The field is blank/missing for some users.”
• “Sharing works… sometimes.”

Fast path: diagnose in 10 minutes

Goal: prove whether it’s record access, privilege, or field-level security.

1. Confirm the environment + exact user
   • Which environment (Dev/UAT/Prod)
   • Which user (not “someone on the team”)
2. Get one known record
   • Record URL + GUID
   • Who owns it (User/Team)
   • Business Unit of owner
3. Test as admin and as the user
   • If admin can see it but user can’t → it’s security, not “the view.”
4. Classify the failure
   • Can’t see the record at all → record-level access (ownership/scope/sharing)
   • Can see but can’t edit → privileges (Write) or field security
   • Can’t relate/set lookup → usually Append/Append To (or missing Create on related table)
   • Field missing/blank → field security profile or form differences
5. Make one change, retest
   • Don’t change 4 things at once. You’ll “fix” it and not know why.

Future You will thank you.

Plain-English mental model

Dataverse security is basically:

1) “Can you access this record?”

That depends on:

• Ownership (who owns it)
• Role scope (user/BU/parent-child BU/org)
• Sharing (teams/access teams, explicit shares)

2) “Can you do this action on that table?”

That depends on privileges:

• Create / Read / Write / Delete
• Plus special ones: Append / Append To

3) “Can you see/edit this field?”

That depends on:

• Field-level security profiles
• Whether the field is on the form (and visible)

Decision tree: missing record vs can’t edit vs can’t relate

A) “User can’t see the record”

1. Can the user open it by direct URL?
   • No → record access issue
   • Yes → view/filter issue (or the record is filtered out)
2. Who owns the record?
   • Owned by someone else / team / different BU?
3. What is the user’s privilege scope for Read on that table?
   • User-level Read means: only their own records
   • BU-level Read means: records owned in their BU
   • Org-level Read means: everything
4. If access needs to cross ownership boundaries:
   • Use owner teams, access teams, or specific sharing strategy
     (“Just make everyone org-level” is not a strategy.)

B) “User can see it but can’t edit/save”

1. Does the role include Write on the table?
   • If not, that’s your answer.
2. Is the field they’re changing actually secured?
   • If field-level security is enabled and they don’t have the profile, it will look read-only / hidden.
3. Is the record status preventing edits?
   • Some status reason patterns block edits (by design).

C) “User can’t create related things (Notes/Activities/etc.)”

1. Do they have Create on the related table?
   • Notes = Annotation (in classic terms)
   • Activities = Task/Email/etc.
2. Do they have the right privileges to associate it with the parent record?
   • This is where Append / Append To shows up.

D) “User can’t set a lookup / relate records”

This is the classic:
“They can create the record, but they can’t set the lookup.”

That is usually Append + Append To.

Append vs Append To (finally explained)

These two are confusing until you think of them as permission to link things together.

Example: Setting a lookup (Contact → Account)

When a user sets the Account lookup on a Contact, the system is creating a relationship:

• Contact is being attached to Account

To allow that, the user generally needs:

• Append on the table being updated (Contact)
  (permission for Contact to “append” something to itself — i.e., hold a relationship)
• Append To on the table being referenced (Account)
  (permission for Account to be appended-to by other records — i.e., to be a parent in a relationship)

Super simple rule

• Append = “this record can connect to others”
• Append To = “other records can connect to this”

If someone can’t set a lookup and everything else looks fine, check these first.

Recommended approach: personas → roles → teams

This is the clean way to build security that scales.

Step 1: Define personas (3–6 max to start)

Examples:

• Staff user
• Supervisor
• Finance
• Admin support
• Integration/service account (separate)

Step 2: Map top tasks per persona

Write down real actions:

• create case
• assign owner
• update status
• upload documents
• create notes
• relate contact to account

Step 3: Build roles with least privilege first

• Start tight, expand intentionally.
• Prefer BU/team strategy over org-wide access.

Step 4: Use teams for cross-cutting access

Good uses:

• Access team templates for “collaboration on a record”
• Owner teams for shared ownership across a group

Step 5: Only use field security for truly sensitive fields

Examples:

• SSNs, bank info, compensation, medical info
  Not:
• “fields we don’t feel like placing on forms”

Common gotchas

• Testing as admin hides the real problem.
• The record is owned by a different BU and the user has only BU-level Read.
• User has Write but can’t set lookups because Append/Append To is missing.
• Field looks “missing” because of field-level security profile, not form design.
• Notes/Activities fail because user lacks Create on the related table.
• “Sharing works sometimes” because there’s no consistent team/access team strategy.

Consultant law #12: If the user can’t set a lookup, check Append/Append To before you redesign the entire security model.

Definition of Done

You’re done when:

• ☐ You can explain in one sentence whether it was record access, privilege, or field security
• ☐ The user can complete their core tasks end-to-end
• ☐ Access is granted by a repeatable model (roles/teams), not one-off sharing
• ☐ You tested with a real user role (not admin)
• ☐ You documented: who owns what + which teams grant cross-access

Future You will thank you.

Printable checklist + templates

Security Debug Checklist (copy/paste)

Confirm

• ☐ Environment (Dev/UAT/Prod)
• ☐ User identity + role(s)
• ☐ One record GUID + who owns it + owner BU

Classify

• ☐ Can’t see record (record access)
• ☐ Can see but can’t edit (Write / field security)
• ☐ Can’t relate / set lookup (Append/Append To)
• ☐ Field missing/blank (field security / form)

Verify privileges

• ☐ Read scope correct (User/BU/Org)
• ☐ Write exists where needed
• ☐ Create exists for related tables (notes/activities)
• ☐ Append on the “child” table
• ☐ Append To on the “parent” table

Retest

• ☐ Retest as real user
• ☐ Confirm the specific action now works

Persona → Tasks worksheet

• Persona:
• Must do (top 10 tasks): 1. 2. 3.
• Tables involved:
• Privileges needed:
• Cross-access strategy (team/access team?):