Addressing Complex Security Models for Dynamics 365 US Government Implementations

Resources

Arctic IT News, Articles and Events

Complex Security Model for Dynamics 365 US Government

Publish Date

July 1, 2025

Categories

Blog | Government Blog | Microsoft Dynamics 365

Tags

Dynamics 365 US Government | Security Model
Are you implementing Dynamics 365 for a government organization with a complex security model, and you don’t know where to start? First, know that this is a very common occurrence. Breaking down this process into steps takes away the complication and ensures each user has the correct access and security clearance for accessing government data.

With the launch of Dynamics 365 US Government (formerly known as Microsoft CRM Online Government), government entities benefit from enhanced security measures, including the use of Azure Government Cloud services, Microsoft Dataverse, and other compliance-driven solutions. These business applications are generally available to customers through deployment into the Microsoft Government Community Cloud (GCC). Additionally, the GCC requires comprehensive background checks for administrators, ensuring that only authorized personnel can manage sensitive government data.

All these added layers of security are great in ensuring that the data is safe from outside forces, but what about the forces inside of Dynamics 365 – those “forces” being the government organization’s users? Without a security model in place, users can access, create, edit and delete all data in the system.

This security model may work for some government entities, but many implementations require a separation of data from one “area” (Department, Agency, Team, etc.) to another, as well as additional security to determine what a user can do with that data once they have access to it.

So, where to begin? Let’s first look at why it is so important to have the proper security architecture.

 

The Importance of a Security Model

Security can be a complex, but very important, undertaking. Security impacts every single user in the system. Without a proper security model, your system is wide open, allowing users access to all information across your entire organization.

While this may work for some organizations, most require some type of control over their data in terms of what data a user can create, read, update and most importantly, what they can delete.

With that in mind, we’ll now discuss the different levels of security, including system-level access and record-level privileges, and how these play into your organizational structure.

 

Security Levels in Dynamics 365

The following addresses the different security levels in Dynamics 365 and what part they play for users in the system.

System-Level Access

These levels determine what data a user can access across the organizational structure.

System Level Access in Dynamics 365 US Government

Record-Level Privileges

Individual users are assigned to these organizational structures to limit what data or records they can access. The following are a few rules to be aware of regarding business units and teams:

  • Individual users can only be assigned to one business unit
  • A team can only be assigned to one Business Unit,
  • Individual users can be assigned to multiple teams, thus a team can include users from the same or different business units

Once a user has been assigned to a business unit and team, you’ll need to determine what you want the user to be able to do with the records they can access.

The following privileges describe record-level privileges in Dynamics 365.

Record-Level Privileges in Dynamics 365

Throughout this guide, we will be using the following imaginary university and its related high-level organizational structure and data.

  • Company:
    • Wyndam University
  • Departments:
    • Admissions
    • Financial Aid
    • Marketing
  • Departments and Associated Teams:
    • Admissions
      • Student Records
      • Campus Enrollment
      • Online Enrollment
    • Financial Aid
      • Grants
      • Student Loans
    • Marketing
      • Student Portal
      • Social Media
  • Departments and Associated Tables/Forms:
    • Admissions:
      • Student Records
        • These forms contain PII (SSN numbers, address, etc.)
      • Campus Enrollment Application
      • Online Enrollment Application
    • Financial Aid:
      • Federal Pell Grant Application
      • Student Loan Application
    • Marketing:
      • Student Portal Access Request
      • Social Media Access Request

 

Step 1: Requirements Gathering

With the security knowledge above, combined with the added information regarding the university’s organizational structure and data, we can begin to compile questions for the Customer to further define their security model.

  • Parent/Child Business Units (Departments):
    • Will multiple departments be using the system?
      • As we have determined above, the university will have three departments: Admissions, Financial Aid and Marketing, so the answer is Yes
    • Will the departments access the same type of records?
      • Example: Will multiple departments be able to access “Student Records” across the organization?
      • If yes, do access levels need to be restricted between the departments?
        • Example: Does the “Social Media” department need to be restricted from accessing editing Student Records?
        • If yes, your security model will need to include record-level access
  • Business Units (Teams):
    • Can a user be on multiple teams in their own, or other, departments?
      • If yes, your security model will require teams with assigned users
  • Tables and Forms (previously known as Entities)
    • Should a user be restricted from seeing all the tables and related forms in their department, or other departments, for which they have access?
      • If yes, your security model will need to include form-level security
  • Column-Level Security (previously known as Field-Level Security)
    • Should users be restricted to seeing specific fields on the forms to which they have access?
    • Example: Social security numbers?
      • If yes, your security model will need to include column-level security

With the above questions, we’ll begin to lay out the security model requirements for Wyndam University:

  • All data in the system must be separated by the three different departments (or Business Units)
    • Admissions
    • Financial Aid
    • Marketing
  • President:
    • The President is the only user at the university who is at the topmost level of the organizational chart
    • The President must be able to see all data across the entire organization
    • The President cannot create or edit any data for the organization
  • Director:
    • The Director is the only user at the university who oversees both the Admissions and the Financial Aid Departments
    • The Director must be able to see all data in both departments
    • The Director must be able to create and edit all tables and forms in the Admissions and Financial Aid departments
    • The Director must not have access to the Marketing Department
  • Managers:
    • Managers can create and edit all tables and forms in their business unit
    • The Manager of Student Loans must be able to view all applications for Federal Pell Grants
  • Student Records:
    • The Director must be able to create and edit all student records
    • The Managers of Campus Enrollment and Online Enrollment must be able to create and edit all student records
    • The Manager of Student Portal must be able to view all student records
    • The Manager of Social Media does not need access to student records
  • Social Security Numbers:
    • The Director must be able to create, edit and delete all students’ social security numbers
    • The Manager of Campus Enrollment and Online Enrollment must be able to create and edit all students’ social security numbers
    • The Manager of Student Loans and Student Portal must be able to only view student records
  • Delete Records
    • The Director is the only user who can delete records in the Admissions and Financial Aid departments

If we applied the above information to a security model, it would look like the following:

Example Security Model in Dynamics 365 US Government

 

Step 2: Creating Security Requirement Documentation

Whether you’ll be implementing security or creating requirements for someone who will be, you’ll need to create documentation to make it more understandable.

To follow is an example of a completed requirements document to help you or your team effectively implement security in Dynamics 365.

Sample Security Requirements Documentation for Dynamics 365

Legends:

Sample Security Requirements Documentation Legends

 

Why the Dynamics 365 Security Model

In summary, the Dynamics 365 security model for Dynamics 365 US Government provides a structured and efficient way to manage data access, ensuring that users can only interact with the information necessary for their roles. By leveraging business units, role-based security, and field-level restrictions, organizations can safeguard data integrity, privacy, and compliance while enabling seamless collaboration – even with complex security requirements. Implementing this model correctly not only protects sensitive information but also enhances operational efficiency by preventing unauthorized access and streamlining user permissions.

With a well-designed security framework, you can confidently maintain control over your data while supporting the needs of your organization. If you’re looking for a partner to help you confidently embark on this journey, we can help. Arctic IT has extensive experience in supporting government agencies and organizations with their Dynamics 365 implementations in the Government cloud. Reach out to us today to get the conversation started.

Part 2: Implementing the Security Model in Dynamics 365

Stay tuned for Part 2: Addressing Complex Security Models, where we’ll walk through creating all the segments of the security model that are discussed above in Part 1. This will include creating business units, teams, and security roles, then assigning users and privileges to each.

Debi Shafer

By Debi Shafer, Senior Client Services Consultant at Arctic IT