Secure and collaborative working on the new CRM platform

The programme including Microsoft and their partners have been working to design a security model in the CRM Platform that reflects the University’s unique structure, particularly the collegiate system and the importance of managing relationships with students and alumni. We have created business units and Role Based Access Control that supports secure and collaborative working across Oxford. 

What are business units and how do they work?

A business unit is a way to group platform users, records, and resources. We have created a business unit for each college and are all grouped under parent unit specifically for colleges. All colleges have access to all other college's unrestricted data, because they are under the same parent unit. There are additional layers of security for restricted and VIP records, such as discrete entities. Anything that is deemed sensitive or restricted, like donations or sensitive emails will need to be placed into the business unit’s discrete entity. The data within the discrete entity is accessible based on the roles of users within that business unit. 

This model will be rolled out across Oxford with business units for departments and functions that are then grouped under the appropriate parent unit. This setup helps to manage who can see and work with which records. This also ensures that records can be “owned” by a college, department, or function and not a platform user.

How does Role Based Access Control (RBAC) Support Security? 

RBAC ensures that users only see the data they need for their specific role. Across the Collegiate University different teams manage different types of data and have different requirements for its use.
Access is controlled in two different way:
Security roles, define what actions a user can take with data (such as view, edit, or delete)
Access levels, determine how much data a user can see. There are four different levels of access that can be assigned to a user: 

• Basic access, allows users to see only their own records
• Local access, includes records within their college or department (business unit)
• Deep access, includes their parent unit and any business units that belong to the parent unit 
• Global access, includes all records across the Collegiate University

This allows data access to be much more controlled across the platform.

Green Templeton College data example: 

Sarah Makington, in Balliol College will have access to unrestricted shared data held by Green Templeton College. This would allow Sarah to see if a record was connected to a different college. 

If someone were to donate to Green Templeton College, that gift is deemed as restricted data and would then be attached to a discrete entity within the Green Templeton College. Sarah would not be able to view that data. However, Tobi Adekule, a development manager who works for Green Templeton, will have greater access to data that is held under the Green Templeton business unit. This allows Tobi to create reports on the records within Green Templeton. 

Sarah from Balliol and Tobi from Green Templeton both have access to Green Templeton college data, as the data belongs to a college business unit that sits under the college parent unit but their level of access it different. 

Why this is important

• Each college can own its data, such as alumni records or donations, while still being part of a wider, connected system.
• Colleges users can access shared (unrestricted) data from other colleges, but sensitive data like VIP records or donation details are kept private within each college’s restricted business unit.
• Access to records is based on your role. For example, a staff member in one college can see their own college’s data and shared data from others, but not sensitive records from another college unless they have specific permissions that would allow them to access this information.
• DAE staff can access records they own, such as non-alumni donors, and view shared data from colleges, but not items withing the discrete entity, like donation details unless explicitly permitted.

What About Documents?

Documents stored directly in the CRM platform will follow the same security rules. If you can’t see the record, you won’t be able to see the document.
For documents stored elsewhere, such as SharePoint, the platform will show you a link to the document if you have access to read the record. Access to the document itself depends on the permissions in that specific storage system.

Data Model and Security 

The CRM programme is implementing a Common Data Model (CDM) and modern Data Governance processes. This is to support different business systems such as The CRM platform, Power BI, Azure and other Microsoft power apps to work together. This model ensures that data is consistent, well-structured, and future proofed. 

Common Data Model (CDM)

The CDM provides a shared structure for data across Microsoft tools such as Dynamics 365, Power BI, Power Apps, and Azure. This makes it easier for different systems and teams to work together.
The common data model supports different types of data:

• Master data, such as people and organisations
• Transactional data involving money, like donations or event registrations
• Configuration data, including system settings
• Inferred data, such as engagement scores

For example, if a college records a donation on the CRM platform, that same data can be analysed in Power BI without needing to reformat it.

Auditing and Logging

Auditing and logging features provide full visibility on how data is used and changed, supporting compliance and accountability. While automatic logging of key activities as record creation, updates, deletions, and role changes; Administrators can choose which data is audited, helping balance visibility and system performance. Logs are stored securely and can be reviewed when needed. 
The system records:

• Who accessed or changed a record
• What was changed and when
• Changes to sharing permissions and security roles

All logs are stored securely and retention policies are configurable to meet compliance needs. 

Data Minimisation and Governance

Data minimisation is a key principle of data protection and privacy regulations such as GDPR, collecting, processing and retaining the minimum about of personal data protect the privacy of our communities. This means collecting only the data needed for a specific task, restricting access to sensitive fields, and removing old or unused data.
Governance is built into the system through:

• Clear data ownership at the business unit level
• Standard data definitions using the Common Data Model 
• Regular reviews of access roles and data quality

This approach supports better decision-making, improves the experience of our communities especially our students and alumni, and ensures that data is managed responsibly and securely.