ASD01 Blue Prism Solution Designer: Retirement and Today's Design Path

ASD01, Designing Blue Prism Process Solutions, was the examination behind the Blue Prism Solution Designer certification. It tested whether an experienced developer could turn business requirements into a scalable, secure, recoverable, and supportable Blue Prism solution. The certification is now retired: Blue Prism set July 31, 2025 as the final day to take the Solution Designer exam and moved its key design topics into the refreshed Professional Developer program.

That retirement does not make ASD01 irrelevant. The design problems it addressed still exist whenever an automation is expected to run unattended, handle exceptions, protect data, scale across workloads, and remain maintainable after handover. The current Blue Prism certifications simply validates those skills differently. Candidates reading an ASD01 page should separate the historical exam from the modern competencies that survived it.

ASD01 tested solution judgment rather than interface recall

The historical certification overview described 27 multiple-choice questions in 60 minutes with a 70% pass mark. The first five questions were long scenarios and carried disproportionate weight. That structure reflected the nature of solution design: a designer must interpret a situation, identify constraints, and choose among several technically possible approaches. The question is often not whether Blue Prism can do something, but which design gives the best combination of resilience, clarity, security, and operational control.

Historical scope included unattended automation, sub-processes and wrapper objects, recoverability, scalability, object design, case and workload management, data management, and web services. These topics are interconnected. An object design choice affects recoverability; queue design affects scalability; data handling affects security; and integration choices affect how easily a solution can be tested. Effective preparation therefore connects design decisions rather than memorizing isolated best-practice statements.

Unattended automation must make state explicit

A person can compensate for an application that opens on the wrong screen or produces an unexpected prompt. An unattended process cannot rely on intuition. The solution needs clear start conditions, deterministic navigation, validation of application state, controlled cleanup, and restart behavior. The designer should know what happens if a runtime resource begins work after a previous session failed, if an application is already open, or if a transaction was partly completed before an exception occurred.

Idempotence becomes important whenever a process can be retried. If the automation submits a payment, creates a record, or sends a message and then fails before recording success, blindly repeating the transaction may duplicate a business action. A robust design includes business keys, status checks, or reconciliation so that the process can establish what actually happened. This kind of reasoning is more valuable than simply adding recover stages around every page.

Process decomposition should improve responsibility boundaries

Sub-processes and reusable pages are useful when they represent coherent pieces of behavior. Excessive decomposition can make a solution harder to trace, while a single enormous process hides business meaning and increases change risk. A designer should separate orchestration from repeated actions, isolate application interaction in objects, and create page boundaries that correspond to meaningful steps or reusable logic.

Wrapper objects can provide a stable interface around lower-level application objects. That pattern is valuable when multiple processes need the same business action but should not know every UI detail required to perform it. Changes to selectors or navigation can then be contained within the object layer. The same principle underpins the current Blue Prism Developer curriculum: reusable object and process design reduces the number of places a change must be understood and tested.

Recovery design begins by classifying failure correctly

Not every exception should trigger the same response. A business exception, such as invalid source data, may require the item to be rejected and reported. A transient application or network failure may justify a controlled retry. A failure that leaves application state uncertain may require cleanup before the next item starts. Designers need to preserve meaningful exception detail while preventing one failed transaction from corrupting the session that follows.

Recovery also has an operational dimension. Support teams need enough logging to see where and why a process failed, but logs should not expose secrets or sensitive data. The process needs a known restart point and a policy for incomplete items. A solution that can only be recovered by the developer who built it is not production-ready, even if it works perfectly in a demonstration environment.

Work queues are the backbone of scalable transaction processing

Queues separate the definition of work from the runtime resource that performs it. A well-designed queue can store business keys, priority, tags, transaction data, status, attempts, and exception information. Multiple digital workers can process items without colliding because queue locks establish item ownership. This makes queues a natural foundation for scale-out, but only when the solution defines what constitutes a transaction and how retries should behave.

Designers should think about workload distribution, service levels, and dependencies. Priorities can help urgent work move first, but excessive priority rules make behavior difficult to predict. Tags can support routing or reporting, but they should have stable meaning. Retry limits should distinguish transient technical failures from deterministic business outcomes. The objective is not to use every queue feature—it is to make workload behavior observable and controlled.

Data design affects security, performance, and auditability

Automation solutions often move personal, financial, or operational data between systems. Designers should minimize what is retained, choose appropriate data structures, avoid unnecessary exposure in logs, and use credentials rather than embedding passwords in process logic. Collections are convenient, but carrying a large dataset through every page can create performance and debugging problems. Data should be available where it is needed without becoming uncontrolled shared state.

Audit requirements also influence design. A business may need to know which item was processed, what decision was taken, when an external system was updated, and whether a human intervention occurred. That does not mean logging every field. Good audit design records enough evidence to reconstruct significant events while respecting confidentiality and retention requirements. The strongest solution designs treat data governance as part of functionality, not an afterthought.

Integration choices should favor stable interfaces

ASD01 included web services because a solution designer must decide how systems should interact. Screen automation is powerful when no better interface exists, but APIs and service interfaces can be more stable, faster, and easier to validate. The choice depends on the target system, security, support model, licensing, and available controls. Designers should understand the trade-off rather than assume that using the visual interface is always the most 'Blue Prism' approach.

The same principle applies to application objects. A direct service call should still be wrapped in a clear contract, with explicit inputs, outputs, timeouts, error handling, and authentication. If an integration becomes unavailable, the process should fail in a way that preserves transaction state and gives operations useful evidence. Architectural cleanliness matters most when dependencies are unstable or changed by teams outside the automation program.

Solution design now lives inside the refreshed Professional Developer path

Blue Prism retired Solution Designer because its key topics were integrated into the refreshed Professional Developer certification. The current Professional Developer program goes beyond the old ASD01 scope by combining solution design with advanced exception handling, advanced work queues, browser automation, credentials, APIs, testing, deployment, and leadership. Blue Prism recommends one year of hands-on experience and requires candidates to have passed the Developer exam.

The current Professional Developer exam has 50 questions in 75 minutes and uses a scaled passing score of 600 or higher. Its published domains are Object Development, Process Development, Process Implementation, and Leadership. Solution design best practice is incorporated into Process Implementation rather than isolated in a separate credential. That change makes the design discipline part of advanced development practice rather than a parallel certification branch.

ASD01 materials can still be valuable for practicing architectural judgment. Take each scenario and identify its transaction boundary, failure modes, application dependencies, data sensitivity, queue strategy, scaling assumptions, recovery point, and support requirements. Then compare the design with current Blue Prism guidance. This approach preserves the intellectual value of the old exam without relying on retired registration rules or outdated product assumptions.

The strongest takeaway from ASD01 is that maintainable automation begins before development. When design decisions make state, responsibility, data, integration, recovery, and workload behavior explicit, development becomes easier to test and operations become easier to support. The certification code has retired, but that design discipline remains central to the current Blue Prism Developer and Professional Developer paths.

Nonfunctional requirements belong in solution design from the beginning

Business requirements explain what an automation must accomplish, but production viability also depends on throughput, operating windows, security, auditability, recoverability, and support expectations. A process that handles ten items correctly in a test environment may not meet a two-hour overnight window for ten thousand transactions. Likewise, a design that stores sensitive input in verbose logs may satisfy functional testing while failing a security review. Solution design should make these constraints visible before developers optimize the wrong behavior.

Designers should quantify assumptions where possible. Estimate transaction duration and expected volume, identify peak periods, define how many concurrent sessions are allowed by target applications, and document recovery objectives. If the business needs same-day completion, the architecture should show how workload will scale and what happens when capacity is lost. These questions prevent performance and resilience from being treated as deployment surprises.

A useful design review asks another experienced practitioner to test the logic of the proposed solution. Reviewers should look for hidden application dependencies, unclear transaction boundaries, missing recovery paths, insecure data handling, and scaling assumptions that have not been measured. The purpose is not to force every designer into identical diagrams; it is to expose risks while the solution is still inexpensive to change. Recording the decisions and unresolved assumptions also gives developers and testers a clearer contract for implementation.