Power Platform Interview Questions

A model-driven app is like ordering an IKEA kit — the pieces and instructions are already matched to what you're building, so you assemble something consistent fast. A canvas app is more like building furniture from raw lumber — far more freedom over exactly how it looks, but you're responsible for every measurement yourself. Model-driven apps fit when the app is primarily driven by the Dataverse data model itself — forms, views, and business logic generated largely from the tables, with a consistent, standardized UI you don't need to hand-design. Canvas apps make sense when the requirement is a highly specific, pixel-level user experience, when the app needs to pull data from many different sources beyond Dataverse in a single screen, or when it's targeted at a narrow task-based workflow rather than full CRUD across a data model.

It's like building most of a room from an IKEA kit but having one custom-built shelf made for an awkward corner the kit doesn't cover. Yes — a canvas app can be embedded directly inside a model-driven app form or as a custom page, a common pattern when most of a requirement fits the model-driven paradigm but one screen needs a more custom, task-specific interface than a standard form can provide. That avoids an all-or-nothing choice between the two app types for a single project.

Patch is the moment you actually staple a change into the underlying record — everything before that is just moving pieces around on the workbench. Patch writes data back to a data source — creating a new record or modifying an existing one — and it's the function you use any time a canvas app needs to persist a change to Dataverse or another connected source. Setting a variable with Set or UpdateContext only changes in-memory state within the app's session; nothing is saved to the underlying data source until a Patch, or an equivalent submit action like SubmitForm, actually runs.

A collection is like a shopping cart holding a whole list of items you're carrying around the store before checkout; a single variable is like holding just one item in your hand. A collection, created with Collect or ClearCollect, holds a table of multiple rows and is used to cache a list of records locally in the app, often to avoid repeated calls to a data source or to hold data being built up before a bulk save. A single record variable, set with Set, holds one value — a single record, a number, a string, or anything else — and is the right tool when you don't need a whole table's worth of rows.

Hiding a button based on role is like removing a sign from a door — it discourages the casual visitor but doesn't actually lock anything. I'd typically use the User() function combined with a lookup against a permissions or role table inside the Visible property of the control, evaluating to true or false based on that lookup. For anything beyond simple UI convenience, actual data protection, I'd rely on Dataverse security roles and table permissions as the real enforcement layer, since hiding a control in the app doesn't stop a determined user from reaching the underlying data another way.

A business rule is like a set of standing store policies that apply no matter which aisle a customer is in; a Business Process Flow is more like a numbered set of stations a customer has to pass through in order to check out. A business rule applies form-level logic — showing/hiding fields, setting values, applying validation — that can run on a form, and optionally at the table level independent of any specific form, without writing JavaScript, and it applies regardless of which stage a record is in. A Business Process Flow instead guides a user through a specific ordered sequence of stages and steps for a process like Lead-to-Opportunity, enforcing what's required at each stage; they're often combined, with a business rule handling field-level logic within a stage the BPF is driving the user through.

Cloud flow triggers work a lot like the different ways a doorbell camera can start recording — motion at the door, a scheduled nightly check, someone pressing the button themselves, or a signal from another connected system. The main categories are automated triggers, fired by an event like a new email arriving or a Dataverse row changing; scheduled triggers, run on a recurring time-based schedule; instant triggers, fired manually by a user, such as a button in a canvas app or a manual run-flow click; and business process flow triggers tied to a stage change in a Dataverse BPF.

A flow reacting to a Dataverse change is like a doorbell camera sending you a notification after someone's already knocked and left — it can't reach back in time and stop them from knocking. Dataverse triggers fire on row create, update, optionally scoped to specific columns, delete, or when a record is added to or removed from a team, and the flow always runs asynchronously — it's queued and processed after the triggering operation has already completed. That's the key contrast with a synchronous plugin: a flow can never block or roll back the save that triggered it, so it's suited to logic that reacts after the fact, like sending a notification or updating a related system, not logic that must prevent the original operation from happening.

Sending a confirmation email is the classic "notify, don't gatekeep" job — nobody needs to wait at the counter for it to happen, so it belongs in the background. Sending a booking confirmation email or a Teams notification when a record is created is a typical fit — it's not something that needs to block the user's save, it often needs to reach outside Dataverse to a connector like Outlook or Teams, and building it as a flow means a non-developer can see and adjust the logic later without redeploying code. Anything time-based, like a reminder sent 24 hours before an appointment, is also naturally a scheduled or delayed flow rather than plugin logic, since a plugin only runs in response to an operation happening right now.

It works like routing a purchase request to a manager's inbox for a thumbs-up or thumbs-down before it moves forward. An approval flow uses the Approvals connector to create a request that's routed to one or more specified approvers, who receive a notification — email, Teams, or the Power Automate mobile app — and respond Approve or Reject, often with comments. The flow then branches on that outcome, updating a Dataverse record's status, sending a follow-up notification, or triggering further steps, and supports patterns like requiring all approvers to agree or accepting the first response, depending on how the approval step is configured.

It's like having a backup plan for the one delivery step that's most likely to go wrong, instead of letting the whole shipment stall silently if that one step fails. I'd wrap the steps that are more likely to fail, such as an external HTTP call, in a Scope, configure a parallel run-after branch that triggers only on failure, timeout, or skipped, and use that branch to log the failure, send an alert, or attempt a controlled retry rather than letting the flow just stop. Built-in retry policies on individual connector actions handle transient failures automatically, but they don't replace explicit handling for the case where a step fails permanently and someone needs to know about it.

A custom connector is like teaching Power Automate to speak a dialect only your company's internal system understands, when no ready-made phrasebook exists for it. A custom connector is a definition, built from an OpenAPI/Swagger definition or configured manually, that lets Power Automate and Power Apps call an API without a pre-built connector already available in the standard list, such as an internal company API. It's the right tool whenever a flow needs to talk to a system Microsoft hasn't already built a connector for, and it can be configured for authentication types, like an API key or OAuth2, that match what that specific API requires.

The gateway is the one physical door a cloud flow has to walk through to reach something sitting inside a private building — and if that door gets stuck, nothing gets through. A flow needs the gateway whenever a step has to reach a data source that isn't reachable from the public internet, such as an on-prem SQL Server, and the gateway acts as the secure bridge between the cloud flow and that internal resource. The main limitation is availability and performance: the gateway runs on a machine, or cluster of machines, someone has to keep online and patched, and if that machine is down, every flow depending on it fails — an operational dependency the rest of the cloud-only automation doesn't have.

Import mode is like photocopying a document to work from your own copy; a live connection is like reading straight off the original, which is always current but means waiting on whoever's holding it. Power BI can connect live via the Dataverse connector, using DirectQuery-style or import mode against the underlying data, or through dataflows and the Common Data Service connector for a more curated, reusable data preparation layer, or via Azure Synapse Link for large-scale analytical workloads too heavy for a direct connection. Import mode copies data into the Power BI model on a refresh schedule and is generally fastest for report interaction; DirectQuery-style connections query Dataverse live on each interaction, trading some performance for always-current data.

A calculated column is like a price tag printed on an item ahead of time — fixed once it's stuck on; a measure is more like the running total the cash register calculates fresh at checkout depending on exactly what's in the cart. A calculated column is computed row by row and stored physically in the model, so it takes up memory and is evaluated once per refresh, in the context of that single row — useful when you need the result to be filterable or sliceable like any other column. A measure is calculated on the fly, in the context of whatever filters and grouping are currently applied in a visual, and isn't stored — the right tool for aggregations like a sum, ratio, or year-over-year comparison that has to respond dynamically to how a report is being sliced.

Row-Level Security is like a shared filing cabinet in an office where every drawer looks the same to everyone, but each person can only actually open the drawer belonging to their own department. RLS restricts which rows a given user sees within the same shared report and dataset, defined through roles with a DAX filter expression evaluated against the logged-in user's identity. For a regional sales scenario, I'd define a role with a filter mapping region to the user's principal name through a users/region table, assign users to that role in the Power BI service, and the same report then shows each viewer only their own region's rows without needing a separate report per region.

It's like mounting a shared dashboard screen inside a store's back office rather than making staff open a separate app just to check it. Dynamics 365 CE has a native Power BI embedded control that can be added to a form, dashboard, or a dedicated area of a model-driven app, pointed at a specific published report and, optionally, a specific page within it. It respects the Power BI workspace's own sharing and RLS configuration, so the embedded report still only shows a given user the rows their Power BI role permits, consistent with what they'd see opening the report directly in the Power BI service.

It's the photocopy problem again — the copy on your desk doesn't update itself just because someone changed the original down the hall. Import mode takes a snapshot of the source data at refresh time, so anything changed in Dataverse after the last scheduled or manual refresh won't appear until the next one runs. If near-real-time data matters for a particular report, the fix is either shortening the refresh schedule within licensing limits, triggering an on-demand refresh after key events, or switching that specific report, or just the parts that need freshness, to a live or DirectQuery-style connection instead of import.

A star schema is like organizing a warehouse around one central shipping desk with clearly labeled aisles feeding into it, rather than boxes scattered wherever there happened to be space. A star schema organizes data into fact tables — transactional data like bookings or opportunities — surrounded by dimension tables, descriptive lookups like Customer, Product, or Date, connected by single-direction relationships radiating out from the fact table. It matters because Dataverse's normalized table structure doesn't automatically arrive in this shape, and a model built directly on raw, highly relational Dataverse tables without reshaping toward a star schema tends to produce slower, harder-to-maintain DAX and confusing filter behavior across visuals.

Power Pages is like building a public storefront window for people who don't have a staff badge to walk in the back door. Power Pages is Microsoft's platform for building external-facing, low-code websites backed by Dataverse, intended for users who aren't licensed Dynamics 365 CE or Power Platform users at all, such as customers, vendors, or the public, authenticating through their own accounts or an external identity provider. A model-driven app assumes the user is an internal, licensed user working inside the organization's security model; Power Pages solves the problem of letting an external person submit or view a limited slice of data through a public-facing site, which a model-driven app isn't designed for.

A maker is like a shop tenant fitting out their own store; an environment admin is more like the landlord who manages the building's utilities, security, and who's allowed to lease space in it at all. A maker builds solutions within an environment — apps, flows, tables — generally scoped by the security roles and environment permissions they've been granted, without needing rights to the environment's own configuration. An environment admin manages the environment itself: provisioning it, setting its security group restrictions, managing connectors and data loss prevention policies, and controlling capacity — the two roles are deliberately separated so building solutions doesn't require the broader trust needed to administer an environment.

A DLP policy is like a rule that stops an employee from copying files off the company server straight onto a personal USB drive in the same motion. A DLP policy classifies connectors into groups, commonly Business and Non-Business, and prevents flows or apps from combining connectors across those groups in the same app or flow, so a maker can't accidentally, or deliberately, build something that moves data from a business system like Dataverse into a personal, non-business connector like a consumer email or social account. It's a governance control administrators put in place to reduce the risk of unsanctioned data movement out of the organization's managed environments.

Environments are like separate branch offices, each running independently, and solutions are the shipping containers that move an identical set of furnishings from one branch to the next in order. Environments are separate containers, each with its own Dataverse database, security, and set of apps and flows; a typical setup has separate development, test, and production environments. Solutions are the packaging mechanism that moves customizations between them — you develop in an unmanaged solution in the dev environment, export it as managed, and import that managed solution into test and then production, so each environment ends up with the same components without ever being edited directly in place.

Dataverse for Teams is like a starter apartment that comes bundled with your Teams subscription — comfortable enough for one team's needs, but not built for a growing household. A Dataverse for Teams environment is a lighter-weight, Teams-scoped environment created automatically when a Power App or Power Automate flow is built inside Microsoft Teams, with lower data capacity limits and licensing bundled through Teams rather than a separate Power Apps or Power Automate license. A full Dataverse environment supports the complete platform capability set — larger data volumes, the full range of premium connectors and features, and integration with the wider Dynamics 365 CE application suite — and is what you'd provision for an implementation expected to grow beyond a single team's lightweight app.