Historical certification guide. Microsoft retired exam PL-600, Power Platform Solution Architect, on June 30, 2026. Its corresponding Power Platform Solution Architect Expert certification and renewal assessments also retired on that date. This page retains its original exam-oriented title and permalink because it describes a qualification that previously existed; it is not a current booking guide or a promise that the exam can still be taken. The enduring subject is the ability to design, govern and deliver a business solution across apps, data, integrations, identity, operational workflows and organizational constraints.
An architect does not simply select the newest Microsoft tool. The job is to translate an ambiguous business problem into an implementable system that remains secure, supportable and accurate when something goes wrong. Consider a manufacturer replacing a spreadsheet-based equipment repair approval process. Staff report faults, supervisors review priorities, external contractors perform repairs and finance reconciles costs. A solution may use Power Apps, Dataverse, Power Automate, reporting and external communication, but the hardest decisions concern authoritative records, permissions, exceptions, audit evidence and what the receiving operations team will maintain.
What PL-600 assessed before its retirement
Microsoft’s archived PL-600 study guide described work such as gathering requirements, performing solution envisioning and architecture, implementing integrations, modeling security and data, planning application lifecycle management and designing go-live strategies. These historical objectives still provide useful architecture questions, but the published exam blueprint is not an active 2026 assessment. Candidates should not buy a retired code, follow an old booking link or assume that the platform’s current features map directly to the historical weighting.
The earlier qualification targeted experienced architects who could lead design decisions across the Power Platform and Dynamics 365 environments. Such a professional needs to facilitate technical and business discussions, recognize nonfunctional requirements and explain trade-offs rather than merely configure one form. The same responsibility applies whether the organization is deploying a simple approval application, a complex customer service system or a cross-platform agent. The examination history is useful as a record of those expectations, not as a source of current certification eligibility.
Microsoft now offers AB-100, Agentic AI Business Solutions Architect, which emphasizes AI-powered and agentic-first business solutions, integrations, deployment and governance. Microsoft has described the associated expert credential in the transition from PL-600 and other retired business applications certifications. However, AB-100 is not a one-to-one replacement with identical scope or requirements: the new credential has its own prerequisite associate certification rules and current examination study guide. Applicants must check those requirements directly with Microsoft rather than assume historical PL-600 preparation automatically qualifies them.
Begin with requirements and verifiable acceptance
For the repair approval process, start with what the organization must accomplish. A fault should be recorded once, assigned to an appropriate asset, assessed for safety impact, approved by an authorized person and closed only after evidence of completion. Requirements need to cover exceptional cases such as a missing supervisor, duplicate submission, a repair that exceeds a budget threshold and an unavailable contractor. These conditions determine the architecture more strongly than an early choice of app type.
A useful requirements workshop separates stakeholder wishes from binding rules. A supervisor may want one-click approval, while a compliance officer requires a recorded reason and audit trail for high-risk exceptions. A technician may want offline data capture, while finance requires a transaction to be committed centrally before payment. Document which requirement is mandatory, which depends on licensing or network capabilities and what test will prove that it has been satisfied. Unresolved assumptions should appear in a decision log rather than disappear from the diagram.
Define acceptance criteria for normal and denied paths. An approved safety repair may create one work order with a confirmed owner and visible status. A user without the right role must not approve it, view another location’s sensitive records or bypass a required second sign-off. A successful app demonstration is not enough if these negative tests fail. The architect should also establish recovery targets, ownership after release and who can authorize a scope or policy change.
Choose app patterns and data ownership deliberately
Canvas and model-driven Power Apps have different strengths. A task-focused mobile fault report may benefit from a canvas interface, while a case management process with related assets, contracts, owners and approvals may benefit from a model-driven app grounded in Dataverse. These patterns can coexist, but one process should have a clear authoritative data model. The Power Apps architecture decision includes form validation, table relationships, accessibility, delegation, mobile availability and permitted security roles—not just which builder appears easier.
Dataverse can help maintain structured business records and role-based access, but it is not automatically appropriate for every organization’s data. The architect must examine existing systems of record, integration contracts, licensing and retention. An equipment identifier may already be controlled by the enterprise asset management system. Copying that identifier and its status into a second unmanaged table could create conflicting truths. Decide which system owns each record and how changes are reconciled before designing the user interface.
Data modeling also affects analytics. A fault, work order, repair visit and invoice are different entities. Joining them without respecting the grain can inflate incident counts or costs. Test sample relationships using synthetic records and compare reports against a known reference total. A good architecture establishes which events mean “repair complete,” how reopened work is represented and whether a dashboard’s refresh schedule is suitable for the decisions being made. Reporting is part of the solution’s evidence, not a separate decorative phase.
Integrations and automation need explicit boundaries
Power Automate may route approvals or notifications; an API may exchange records with a contractor system; an agent may assist with locating approved procedures. Each integration has identity, permission, data classification, retry behavior and failure handling. A flow that processes a retry twice can create duplicate work orders, while an agent that responds confidently to a question about a private record can leak information. The architect must define idempotency, human confirmation and audit logging where the business process needs them.
For an approval workflow, distinguish an initiated request from a completed decision. The application may send a notification, but delivery of that notification is not the same as authorization to proceed. If the approver is unavailable or a connector fails, the system needs an observable exception and recovery path. A controlled Power Automate workflow can support the process, but its external dependencies and connection permissions must be part of the design.
Integration architecture should also document data movement. A contractor may need a repair ID and authorized site information but not an employee’s private contact details or company-wide asset inventory. An approved API can provide a narrow view instead of unrestricted access to the original table. Use synthetic test records to verify a permitted request and a denied request. The negative test is essential to show that a convenient integration has not expanded a user’s authority beyond the legitimate business need.
Security, governance and environment strategy
A solution architect needs an access model spanning users, administrative roles, service identities, applications and external parties. Distinguish application-level visibility from Dataverse privileges and connector credentials. A staff member’s screen hiding an Approve button does not enforce authorization if another action or API still permits the underlying update. Validate role and record restrictions with separate test identities, and identify which controls are enforced at the source rather than only in a user interface.
Power Platform environment planning should separate development, testing and production to the extent required for the organization’s risk, compliance and licensing. Data policies determine which connectors may be combined or used under particular scopes. Review maker permissions, Dataverse security roles, solution ownership, managed environment capabilities and monitoring. A feature permitted in a test environment may be blocked by a tenant-wide policy in production; this is a design dependency, not a setting to bypass silently.
For AI-assisted components, apply the same care. A Copilot Studio agent that summarizes a safety procedure should cite or derive from the appropriate approved knowledge source and recognize when an action needs human authorization. Agent and prompt changes need testing for sensitive-data disclosure, wrong tool invocation and misleading confident answers. The newer AB-100 pathway places more weight on these agentic-first responsibilities, but the basic principles of data minimization, identity, accountable decisions and safe release remain valid across both eras.
Lifecycle management and operational handover
Solution architecture includes how a change reaches users and how the organization recovers. Store relevant application components in supported solutions, document connection references and environment-specific variables, and test deployments against realistic permissions. Managed solutions and environment pipelines may support release discipline; they do not automatically solve the problem of migrating business records or reversing changes made after publication. Define what can be rolled back, what must be corrected separately and who is authorized to make those decisions.
A realistic pre-release test can include an unavailable contractor API, duplicate fault submission, an invalid asset ID and a denied approval. Record what the end user sees, what the service owner can diagnose and whether any transaction was committed more than once. Restore an earlier solution configuration in a test environment where supported, then check the resulting data state independently. A successful deployment is not the end of the project if nobody can explain a failed run or support the process when the original builder leaves.
Before handover, the operations team should receive an architecture diagram, data dictionary, roles matrix, integration inventory, monitoring plan, known limitations and recovery steps. The sponsor should have evidence that acceptance criteria are met and that unresolved risks have owners. This is the architecture work that remains relevant after PL-600’s retirement: it turns a demo into a system with responsibilities, auditability and an appropriate support boundary.
A realistic learning route after PL-600
Readers who came to this historical article looking for a current exam should not schedule PL-600. First choose a role: Power Apps maker, Power Platform developer, automation specialist, functional consultant, security/governance practitioner or architect of AI-enabled business solutions. Review active Microsoft certification and Applied Skills pages for that role. AB-100 may be relevant to an experienced cross-platform architect working with AI agents; its prerequisites and live study guide matter. A beginner may instead need foundational Power Platform work and supervised practice before tackling expert architecture concepts.
A practical architecture portfolio can begin with the equipment-repair scenario: document a stakeholder brief, two architecture options and their trade-offs, a data ownership diagram, security matrix, failure-mode inventory and test plan. Implement a small authorized prototype, verify one normal and one denied flow, and record the operational handover. Explain which assumptions were made and what remains untested. These artifacts demonstrate durable decision-making without claiming that the retired exam or a new credential guarantees employment.
The central lesson is that the old PL-600 blueprint represented a genuine architecture discipline, but its examination and certification are retired. Current Microsoft qualifications have evolved toward AI-enabled business solutions and may require different experience and credentials. The most reliable preparation is to verify the active issuer requirements, then practice translating requirements into a secure, integrated, recoverable solution whose business result can be tested. A historical certification guide is useful only when it preserves both that professional context and the current status of the exam.