How do you make sure every piece of business software in your company speaks the same language and shares data without copying it a dozen times? That's the problem the core capabilities of the Dynamics 365 platform solve. For the MB-910 exam, understanding this unified foundation — the Common Data Model, Power Platform integration, and security roles — is the single most important concept you will learn, because everything else in the exam builds on it.
Jump to a section
A simple way to picture Core Platform Capabilities and Common Features
Ever wondered how a massive apartment building works when you only ever see your own front door? How does the postman know which flat to drop your package at, and how does the building manager make sure the plumber can fix your leaky pipe without getting access to your neighbour's spare key?
That apartment building is exactly like the Microsoft Dynamics 365 platform. The Common Data Model (CDM) is the building's master blueprint — it defines that every flat has a door, a living room, and a kitchen, even if the furniture inside is different. Power Platform is like the super-flexible tool shed: it gives you a hammer (Power Apps) to build a new bookshelf, a tape measure (Power Automate) to measure the hallway so you know the sofa will fit, and a report card (Power BI) to show the landlord how many flats have working smoke alarms. Security roles are the key system: the building manager has a master key to every flat; a cleaner only has a key to the common areas; a tenant only has a key to their own door and the front gate. In the old days, every new block of flats needed a totally new blueprint from scratch. Now, with the CDM, every builder uses the same standard blueprint — so if you move from one block to another, you instantly know where the light switches are. This saves time, reduces mistakes, and makes it far easier to manage the whole complex.
Let's start with the big picture. Dynamics 365 is a set of business applications from Microsoft for things like sales, customer service, marketing, and finance. But these applications don't work in isolation. They sit on top of a shared platform that provides core capabilities — think of it as the operating system for your business data.
The first core capability is the Common Data Model (CDM). This is Microsoft's standard way of defining business data. For example, a 'customer' in the sales app is exactly the same type of data as a 'customer' in the customer service app. In the past, each application had its own database with its own definitions. When you wanted to connect them, you had to write complex code to map one definition to another. The CDM eliminates that by providing a shared data schema — a set of standard tables (like 'Account', 'Contact', 'Product', 'Order') and relationships between them. When you create a contact in Dynamics 365 Sales, that same contact record exists in the CDM and can be used instantly by Dynamics 365 Customer Service, Marketing, or any other app. This means one source of truth, fewer errors, and faster implementation.
The second core capability is integration with the Microsoft Power Platform. The Power Platform is a suite of low-code tools — meaning you can build apps and automations with very little traditional programming. It has four main components:
Power Apps: lets you build custom apps that sit on top of the CDM. For example, if your sales team needs a mobile app to record meeting notes that syncs to the CRM, you can build it with drag-and-drop components instead of writing code from scratch.
Power Automate: creates workflows — sequences of actions that happen automatically. For instance, when a new lead is added in Dynamics 365, Power Automate can send a welcome email, create a task for the salesperson, and update a spreadsheet in Microsoft Excel.
Power BI: provides dashboards and reports. You can visualise your Dynamics 365 data — like sales pipeline, customer satisfaction scores, or support ticket trends — in real time.
Power Virtual Agents: allows you to build chatbots that can answer common customer questions by pulling data from Dynamics 365 without needing a human.
Because these tools all use the same CDM, anything you build in Power Apps instantly understands your customer data. This integration is why the MB-910 exam frequently asks about how Power Platform extends Dynamics 365 without custom coding.
The third core capability is security roles and role-based access control (RBAC). In any business system, not everyone should see everything. The finance team should see salaries; salespeople should only see their own deals. Microsoft Dynamics 365 handles this through security roles. A security role is a collection of permissions — you can have different levels of access to each entity (like a table for 'Leads' or 'Opportunities'). Permissions are usually set to one of five levels:
None: the user cannot see any records in that entity.
User: the user can see only their own records.
Business Unit: the user can see records belonging to their team or department.
Parent: Child Business Units: the user can see records in their business unit and any sub-units beneath it.
Organisation: the user can see every record in the entire system.
You assign these roles to individual users or teams. For example, a 'Salesperson' role might have 'Read' and 'Write' access to opportunities at the 'User' level, while a 'Sales Manager' role might have 'Read' access to all opportunities in their business unit. This system ensures data security without needing to set permissions on every single record manually.
Why do these three capabilities matter together? Because they form a foundation that makes the whole platform work. Without the CDM, data would be fragmented. Without Power Platform, you couldn't easily extend the system. Without security roles, you'd have a security nightmare. The exam tests your understanding of how these pieces fit together — not just a definition of each one in isolation.
Initial Configuration of Security Roles
An administrator creates or duplicates a security role in Dynamics 365 Settings. They define permissions per entity (like 'Lead', 'Opportunity') and set the access level (e.g., 'User' or 'Business Unit'). This is the first step because it controls who can see and do what before any other work begins.
Assigning Users to Security Roles
The administrator assigns the relevant security role to each user (e.g., 'Salesperson' role to Julie, 'Sales Manager' role to Tom). This step ensures that every user has the right permissions aligned with their job function from day one.
Extending the Common Data Model (Adding Custom Fields)
Using Power Apps (or Dynamics 365 customisation tools), an admin adds a custom field to an existing entity — for example, adding 'SchoolType' to the 'Lead' entity. This is done because standard entities may not cover every business requirement. The field becomes available across all apps using the CDM.
Creating a Power Automate Workflow
The admin or a business user builds a Power Automate flow triggered by an event (like updating a lead status). The flow performs actions such as creating a new opportunity record. This automates repetitive tasks and reduces manual data entry errors.
Building a Power BI Dashboard
A manager uses Power BI to connect to the CDM and create visualisations (charts, tables) showing key metrics like lead conversion rates. The dashboard is shared with relevant users via security roles, providing real-time insights without needing to export data manually.
Testing and Validating Access
The administrator logs in as different users to confirm that each can see only what they should. For example, Julie should see only her leads, and Tom should see all leads in his business unit. This final step confirms that the security roles and customisations work as intended.
Let's walk through a real scenario at a medium-sized company called 'Northern Lights Books', which sells books to schools. They have recently started using Dynamics 365 Sales to track their sales pipeline.
Julie is a sales representative. She logs into Dynamics 365 and opens the 'Leads' view. She sees only her own leads because her security role ('Salesperson') is set to 'User' level for the Lead entity. She cannot see the leads of her colleague Priya, which is exactly as it should be — each rep manages their own territory.
Julie's manager, Tom, has a different security role ('Sales Manager') with 'Business Unit' level access. He can see all the leads across the Sales business unit, but he cannot see finance data or HR records because those are in different business units with separate roles. This is role-based access control in action.
Now, the company realises they need a quick way for Julie to log the type of school (primary or secondary) when she adds a new lead. The CDM's standard 'Lead' entity does not have that field. So the IT team (or even a tech-savvy sales manager like Tom) opens Power Apps and adds a custom field called 'SchoolType' to the Lead entity. Because this field is added in the CDM, it automatically appears in Dynamics 365 Sales, and also in any Power BI reports or Power Automate workflows that use the Lead entity. No coding required.
Next, they want to automate a process: when Julie changes the status of a lead to 'Qualified', a new opportunity record should be created automatically, and the original lead should be marked as 'Closed'. They open Power Automate, pick the 'When a record is updated' trigger on the Lead entity, and add an action to create an Opportunity record and set the Lead status to 'Closed'. The flow runs every time the trigger happens. The entire setup took about 20 minutes.
Finally, the management team wants a dashboard showing how many qualified leads per school type are converting to opportunities. Tom opens Power BI, connects it to the CDM, and builds a simple pie chart. He shares the dashboard with the entire sales team via a security role that grants read-only access to that dashboard.
What did an IT professional actually do in this story? They:
Defined and assigned security roles to users.
Modified the CDM to add a custom field.
Built an automated workflow using Power Automate.
Created a report with Power BI.
Ensured that all of these components worked together seamlessly because they were built on the same shared data platform.
The MB-910 exam tests your understanding of these core platform capabilities at a conceptual level — you are not expected to know how to click through the interface, but you must understand what each capability does and how they relate to one another.
Common exam question types include:
'Which of the following is the purpose of the Common Data Model?' Correct answer: to provide a standardised data schema that multiple applications can use. The trap: answers that say it stores all data in one place (it doesn't — it defines the structure, not a single storage location) or that it only works with Dynamics 365 (it also works with Power Platform).
'A user needs to see all records across the entire organisation. Which security role permission level should they be assigned?' Correct answer: Organisation. The trap: students confuse 'Organisation' with 'Business Unit' or 'User' level.
'Which Power Platform tool would you use to create a mobile app that reads data from Dynamics 365 without writing code?' Correct answer: Power Apps. The trap: Power Automate is for workflows, not apps; Power BI is for reports.
'What is the relationship between the Common Data Model and Power Platform?' Correct answer: Power Platform stores its data in the CDM, so any app built with Power Apps can access the same data as Dynamics 365. The trap: answers that say Power Platform replaces the CDM or that they are independent.
'A manager needs to restrict a new hire to only see their own sales opportunities. Which security role configuration achieves this?' Correct answer: Set the 'Opportunity' entity permissions to 'User' level for that role. The trap: options that change business unit or org level accidentally give too much access.
Concepts they love to test:
The five permission levels: None, User, Business Unit, Parent: Child Business Units, Organisation.
The four main Power Platform components: Power Apps, Power Automate, Power BI, Power Virtual Agents.
That the CDM is a standard data schema, not a database.
That security roles are assigned to users or teams, not to records directly.
Watch out for trap questions that suggest a capability that sounds right but is slightly wrong. For example, a question might ask 'What does the Common Data Model do?' and give an option like 'It synchronises data between Dynamics 365 and external systems.' That is not the primary purpose — synchronisation is handled by data integration tools, not the CDM itself.
The Common Data Model (CDM) is a standardised data schema that allows different applications to share and understand the same business data without custom integration code.
Power Platform includes four main low-code tools: Power Apps (custom apps), Power Automate (workflows), Power BI (reports), and Power Virtual Agents (chatbots).
Security roles define what actions (read, write, create, delete) a user can perform on which entities, and at which level (none, user, business unit, parent/child, organisation).
Every entity in the CDM has a set of standard fields, but you can add custom fields using Power Apps without affecting the underlying schema's integrity.
Role-based access control (RBAC) in Dynamics 365 is assigned to users or teams, not to individual records, making large-scale permission management efficient.
The integration between Dynamics 365 and Power Platform is seamless because they both rely on the same Common Data Model.
These come up on the exam all the time. Here's how to tell them apart.
Common Data Model (CDM)
A standardised schema defining data structure and relationships
Not a physical storage location; data can be stored in various databases
Exists to ensure data consistency across multiple applications
Database
A physical or logical container storing actual data records
Specific technology like SQL Server or Dataverse
Exists to store and retrieve data for a single application or system
Power Apps
Builds custom applications with user interfaces (UI)
User triggers the app by opening and interacting with it
Output is a functional app that can be used on web, mobile, or tablet
Power Automate
Builds automated workflows that run without user interaction
Triggered by events (e.g., record created, schedule, button click)
Output is a set of actions completed automatically (e.g., email, update)
User-level Security Permission
User can see only their own records in that entity
Assigned to roles for individual contributors like salespeople
Most restrictive level that still allows a user to do their job
Organisation-level Security Permission
User can see all records in the entire organisation for that entity
Assigned to roles for system administrators or executives who need full visibility
Least restrictive level and should be used sparingly
Dynamics 365 Sales (capability)
Focused on leads, opportunities, and quote-to-order processes
Primary tool for sales teams managing pipelines and closing deals
Uses the same CDM entities Account, Contact, Opportunity
Dynamics 365 Customer Service (capability)
Focused on cases, service-level agreements, and knowledge bases
Primary tool for support agents handling customer issues
Uses the same CDM entities Account, Contact, Case
Mistake
The Common Data Model is the same as a single database that stores everything.
Correct
The CDM is a standardised schema defining the structure and relationships of data entities. It is not a database itself — data can be stored in different databases, but it follows the same blueprint.
Beginners confuse the concept of a 'common model' (a blueprint) with a 'common database' (a physical storage location) because the word 'data' appears in both.
Mistake
Security roles in Dynamics 365 are assigned per record manually by an admin.
Correct
Security roles are assigned to users or teams and define access levels per entity. The system applies those permissions automatically to all records of that entity — you do not manually set permissions on each record.
People who have used simpler systems (like shared Excel files) where access is set file-by-file assume the same pattern applies here.
Mistake
Power Platform requires programming skills to use effectively.
Correct
Power Platform is designed for low-code or no-code development. You can build apps, workflows, and reports with drag-and-drop components, though some advanced scenarios may need minor code.
The word 'platform' sounds technical and intimidating, leading beginners to think it is only for professional developers.
Mistake
The Common Data Model is only for Dynamics 365 applications.
Correct
The CDM is used by the entire Power Platform ecosystem, including Power Apps, Power Automate, and Power BI. It is an open standard that Microsoft encourages third-party applications to use too.
Because Dynamics 365 is built on the CDM, beginners assume it is exclusive to that product line.
Mistake
Power Automate and Power Apps are the same thing but with different names.
Correct
Power Apps is for building custom applications (user interfaces). Power Automate is for creating automated workflows (processes that run in the background). They serve different purposes, though they can work together.
Both are 'Power' tools and involve automation, so beginners lump them together without understanding their distinct roles.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, the CDM is not a separate database you have to manage. It is a standardised schema (a blueprint) that Dynamics 365 and Power Platform use automatically. You interact with the data through the applications, not through the CDM directly.
No. Power Platform is designed for low-code or no-code development. Business users with minimal technical training can build apps, workflows, and reports using drag-and-drop tools. Advanced features may require a developer, but the core integration does not.
Yes, you can edit a security role at any time. Changes take effect for all users already assigned to that role. This is a key advantage of role-based access control — you update the role once, and every user in that role gets the new permissions automatically.
Power Apps is for creating custom applications with user interfaces (like a mobile form for recording sales visits). Power Automate is for building automated workflows that run in the background (like sending an email when a record is created). They serve different purposes but can be used together.
No, adding custom fields is safe. Standard fields cannot be removed, but you can add custom fields without affecting existing data or functionality. Other apps using the same entity will see the new field and can ignore it if they do not need it.
No. The exam tests conceptual understanding, not step-by-step navigation. You need to know what security roles are, what the five permission levels are, and how they affect data access — not the exact menu path to assign them.
You've finished Core Platform Capabilities and Common Features. Continue through the MB-910 study guide to build a complete picture of the exam.
Done with this chapter?