PL-100 common mistakes
PL-100 · Understand the traps and how to avoid them.
Treating the Microsoft Dataverse as just a database and building every table with plain text columns, then trying to enforce relationships and business rules in canvas app code instead of using Dataverse relationship types and column types.
Candidates with SQL or SharePoint backgrounds default to flat lists and string columns because that is familiar, and they underestimate how much Dataverse gives them for free (lookups, choice columns, calculated and rollup columns, business rules). They also confuse Dataverse with the older Common Data Service naming and never study the current table and relationship model.
What to do instead
Before designing a table, decide the column type deliberately: Choice for fixed option sets, Lookup for parent/child relationships, Currency for money, Date/Time with behaviour set correctly. Practise creating one-to-many, many-to-one and many-to-many relationships and know which side holds the lookup. Use calculated, rollup and formula columns for derived values, and business rules for validation, rather than duplicating that logic in the app.
Choosing the wrong app type for a scenario: building a canvas app when the requirement clearly calls for a model-driven app, or vice versa, and then defending the choice with generic reasons.
Candidates learn one app type well (usually canvas) and try to force every scenario into it. They miss the decision cues in the question, such as 'process-driven', 'consistent forms across records', 'role-based security from Dataverse', 'responsive pixel-perfect UI', 'offline', or 'embed in Teams'.
What to do instead
Memorise the decision matrix: model-driven for Dataverse-centric, process-heavy, security-by-role apps with forms and views; canvas for tailored UI, multiple data sources, offline, and device-specific layouts; Power Pages for external/anonymous users. On every scenario question, underline the cue words and pick the app type they map to before reading the answers.
Confusing Power Automate cloud flow trigger and action semantics, for example using a scheduled flow where a Dataverse row-created trigger is needed, or expecting an approval action to block the flow synchronously.
Candidates memorise flow names but not the execution model. They forget that some actions are asynchronous, that trigger conditions filter before the flow runs, that concurrency and retry settings change behaviour, and that child flows are the supported way to reuse logic instead of copy-pasting actions.
What to do instead
Study the trigger catalogue and the difference between automated, instant and scheduled flows. Learn trigger conditions, the 'Run a Child Flow' pattern, and how the Approvals action returns a response later. Practise one flow that fires on a Dataverse create, calls a child flow, and writes a status back to the row, and be able to explain each step's timing.
Mixing up security model layers: assigning a security role and assuming it grants access, without accounting for business unit scope, team ownership, column-level security, or the difference between sharing and role-based access.
The Dataverse security model has several interacting layers (roles, business units, teams, hierarchy, field security profiles, record sharing), and candidates learn only the role-assignment step. Scenario questions deliberately probe the interaction, such as a user who has a role but the record is owned in another business unit.
What to do instead
Draw the hierarchy: environment, business unit, user/team, security role with privileges at an access level (user, business unit, parent-child, organisation). Practise a scenario where a record must be visible to one team only, and decide between business unit change, team ownership, sharing, or a field security profile. Know that column security requires both a field security profile and the role privilege.
Ignoring the managed versus unmanaged solution distinction and solution layering, then publishing or importing a solution that overwrites customisations or fails to carry dependencies.
Candidates build everything in the default environment and export without thinking about publisher prefixes, solution segmentation, or what happens to components that are not included. They also forget that managed solutions cannot be edited in the target environment and that layering determines which customisation wins.
What to do instead
Always create a custom publisher with a prefix and build in a dedicated unmanaged solution. Know that you export managed for downstream environments, that 'Add Required Components' pulls dependencies, and that layering resolves top-down with unmanaged winning over managed. Practise promoting a solution from dev to test and listing what must be included: tables, apps, flows, connection references, environment variables.
Writing canvas app formulas that rely on delegation-unsafe functions against large data sources and assuming the app will return all rows.
Delegation is a subtle concept: only certain functions and operators can be translated to the data source query, and the rest silently process only the first chunk of records. Candidates test with small datasets where the limit is never hit, so the behaviour looks correct in the maker portal.
What to do instead
Learn which functions delegate for each connector, especially for Dataverse and SharePoint. Prefer delegable filters (equals, startsWith, comparisons on indexed columns) and avoid non-delegable ones inside Filter. Turn on the delegation warning display, test with more rows than the limit, and know the workaround patterns: collect a delegable subset first, or move filtering into a Dataverse view or flow.
Building reports and dashboards on the wrong visual or aggregation, for example putting raw transactional rows into a card visual or using a pie chart for a multi-category comparison, and not modelling the data with a star schema.
Candidates focus on getting a chart to render rather than on the analytical question. They skip data shaping (relationships, measures, date tables) and choose visuals by appearance. Exam scenarios describe a reporting intent and expect the visual and model that answer it correctly.
What to do instead
Start from the question the report must answer, then choose the visual: card for a single KPI, bar/column for category comparison, line for trend over time, matrix for cross-tabulation, scatter for correlation. Build a star schema with a dedicated date table and explicit relationships, and use measures rather than implicit aggregations. Know when to use Power BI paginated reports versus interactive reports.
Confusing Power BI row-level security roles with Dataverse security, or defining RLS roles in the desktop file but never mapping users or testing 'View as role'.
Both platforms have a concept called 'security role' but they operate at different layers. Candidates define a role with a DAX filter, publish, and assume it is enforced, forgetting that workspace membership, dataset permissions, and the 'View as role' test are separate steps.
What to do instead
Treat RLS as a two-part task: define roles and DAX filters in the model, then assign users or groups to those roles in the Power BI service. Always validate with 'View as role' in Desktop and confirm app audiences and workspace roles do not bypass the filter. Be able to state that Dataverse security filters data at the source, while Power BI RLS filters at the model layer.
Designing the data model and app without considering the ALM path, so connection references, environment variables, and environment-specific values are hard-coded.
Candidates build for a single environment and hard-code URLs, SharePoint site names, and connection IDs. They do not study how solutions carry connection references and environment variables, so the solution breaks on import or requires manual reconfiguration.
What to do instead
Use environment variables for any value that differs per environment and connection references instead of direct connections inside flows and apps. Keep a clear dev-test-prod pipeline, export managed solutions, and document the import settings. Practise importing a solution and resolving a missing connection reference and an unset environment variable.
Misreading scenario questions that ask for the 'best' or 'least effort' option and answering with the technically possible but heavier solution, or ignoring stated constraints such as licensing, offline use, or external users.
PL-100 scenarios are written with constraints that eliminate otherwise valid answers. Candidates answer from habit ('I would build a canvas app') and skip the constraint sentence about guest access, no premium licence, or data must stay in Dataverse. They also fail to eliminate options that need a premium connector when the scenario says standard connectors only.
What to do instead
Read the scenario twice and extract the constraints into a short list: users (internal/external/anonymous), licence tier, data location, offline need, volume. Eliminate any option that violates a constraint before comparing the rest. When two options both work, choose the one with least custom code and least maintenance, and be ready to justify why the other fails a stated constraint.