PL-100, Microsoft Power Platform App Maker, retired on June 30, 2024 together with the Power Platform App Maker Associate certification. The exam is no longer a current path, but the professional problem it addressed is still important: turning business requirements into useful low-code applications and automation.<\/p>\n
What changed is the platform around the maker role. Power Apps, Power Automate, Dataverse, Power Pages, Copilot, prompts, AI models, agents, governance, and application lifecycle management are now more tightly connected. A person who studied PL-100 has a useful foundation, but the 2026 skill set is broader and more AI-aware.<\/p>\n
New learners can use Microsoft PL-900<\/a> for orientation and Microsoft AB-410<\/a> for the current Intelligent Applications Builder Associate path. The right choice depends on whether you need fundamentals or hands-on depth building intelligent business applications.<\/p>\n The key is not to search for a one-to-one PL-100 replacement. Preserve the durable maker skills, then map them into the current Power Platform architecture<\/a>.<\/p>\n A strong app maker starts with the business process, not the screen. Who is doing the work? What information do they need? Where do delays or errors occur? Which steps are repetitive? Which decisions require judgment?<\/p>\n Low-code tools can digitize a poor process just as easily as a good one. Before building, map the current workflow and identify the real bottleneck. The correct solution may be an app, an automation, an agent, a report, or a simpler process change.<\/p>\n This mindset remains central in 2026 because AI-assisted creation makes it easier to produce assets quickly. Faster generation increases the need to define the outcome clearly before the platform starts building.<\/p>\n A useful practice is to write a one-paragraph requirement and success measure before opening Power Apps or Copilot Studio.<\/p>\n Also define what should not change. Existing approval rules, audit requirements, ownership, or regulatory controls may need to remain intact even when the user experience is redesigned. Makers who capture those constraints early avoid rebuilding the solution after stakeholders discover that the prototype removed an important business safeguard.<\/p>\n Dataverse provides tables, relationships, ownership, security, auditing, APIs, and solution-aware components. For record-centric business applications, that gives makers a stronger foundation than scattering production data across spreadsheets or unrelated lists.<\/p>\n Makers should understand business keys, relationships, choice values, validation, ownership, and security roles. A poor data model creates complexity in every later layer: formulas become harder, flows need more workarounds, reports become less trustworthy, and agents retrieve inconsistent information.<\/p>\n Good data design also makes integration easier. When the source of truth and record relationships are clear, other apps, flows, and external systems can use the same business model without duplicating logic.<\/p>\n AI does not reduce the need for structured data. It increases the value of accurate, governed records because AI-generated experiences depend on the context they receive.<\/p>\n Use realistic test data while designing. A model that works with ten clean sample records can fail when production contains duplicates, incomplete values, historical records, or conflicting ownership. Testing the data model against imperfect cases is part of maker readiness.<\/p>\n Canvas apps are useful when the maker needs detailed control over layout and interaction. They fit mobile workflows, inspections, guided tasks, forms, operational tools, and experiences where the screen design matters.<\/p>\n Model-driven apps begin with the Dataverse model and are strong for record-centric processes that need forms, views, relationships, dashboards, and security. They can reduce the amount of custom screen work when the process follows structured business records.<\/p>\n The modern maker should be able to choose between them rather than treating one as more advanced. The decision depends on the user experience, data structure, device, process, and maintainability.<\/p>\n Copilot can accelerate app creation, but the maker still needs to test accessibility, responsive behavior, performance, navigation, and whether the generated experience actually helps the people doing the work.<\/p>\n User testing should happen before the application is considered finished. Watch someone complete the real task without coaching. Confusing labels, excessive navigation, slow formulas, and unnecessary data entry become obvious much faster in observation than in a maker\u2019s own walkthrough.<\/p>\n Many useful Power Platform solutions combine an interface with automation. Power Automate can send approvals, update records, notify users, integrate services, move files, and coordinate work across systems.<\/p>\n Production flows need more than a successful happy path. Makers should consider duplicate events, missing data, timeouts, rejected approvals, unavailable dependencies, changes in ownership, and whether a retry is safe.<\/p>\n Connection ownership matters too. A flow built with one employee\u2019s credentials can become fragile when that employee changes roles or leaves the organization. Important automation needs durable ownership and monitored connections.<\/p>\n The maker role becomes more professional when automation is treated as an operational dependency rather than as a convenient background script.<\/p>\n Monitoring should be designed before the first incident. Decide how failed runs are surfaced, who receives the notification, what information the support owner needs, and whether the workflow can be safely restarted. A silent failure in a background process can be more damaging than a visible app error.<\/p>\n Copilot Studio and AI capabilities allow makers to create conversational experiences, use prompts, call tools, retrieve approved knowledge, classify information, and connect agents to business processes.<\/p>\n The maker should distinguish language-driven assistance from deterministic logic. Exact calculations, mandatory compliance checks, and irreversible state transitions are often better handled through explicit rules. An agent is useful when the process benefits from interpretation, guidance, or flexible interaction.<\/p>\n When an agent can act, permissions and confirmation become important. An agent that summarizes a record has less consequence than one that creates a customer, changes a case, or triggers an external workflow.<\/p>\n Modern app making therefore includes basic agent governance: identity, tool access, approved knowledge, logging, evaluation, and clear ownership of the business action.<\/p>\n Evaluation should include failure cases. Test ambiguous requests, missing context, outdated knowledge, unauthorized users, and tool errors. The maker\u2019s job is not only to demonstrate that the agent can answer; it is to understand when the system should decline, ask for clarification, or require human approval.<\/p>\n A personal productivity app does not need the same process as a customer-facing business system. Governance should be proportional to risk and business dependence.<\/p>\n Environment strategy, data-loss prevention policies, connector controls, security roles, sharing, ownership, and support expectations become more important as a solution gains users or touches sensitive information.<\/p>\n Makers should know when a prototype becomes a production dependency. External users, financial impact, regulated data, broad employee use, or integration with critical systems are all signals that the solution needs stronger lifecycle and support controls.<\/p>\nPL-100\u2019s durable skill was problem framing<\/h2>\n
Dataverse remains the foundation for structured business solutions<\/h2>\n
Canvas and model-driven apps solve different experience problems<\/h2>\n
Power Automate turns an app into a business process<\/h2>\n
Agents and AI expand the maker role beyond deterministic workflows<\/h2>\n
Governance grows with the impact of the solution<\/h2>\n