14.2 Discovery & Design Approaches and Solution Documentation

14.2 Discovery & Design Approaches and Solution Documentation

Exam Focus: Two of the seven objectives in the 19%-weighted Implementation Strategies domain are about method rather than product: "recommend the best approach to discover and design the optimal solution" and "design and document the Agentforce Public Sector solution highlighting solution implementation best practices." These items read like generic consulting questions but they are not — the correct answers depend on facts specific to Public Sector Solutions, above all the existence of the Process Library and the standard PSS data models. Discovery that ignores what ships out of the box is the wrong approach, and the exam scores it that way.

---

What Makes Government Discovery Different

Three constraints reshape the method before a single workshop is booked.

1. Procurement fixes the shape of the engagement. The statement of work was written and competitively awarded before the team assembled. Scope changes require a formal change order, sometimes a contract modification, occasionally a re-bid. An approach that assumes freely renegotiated scope is unusable. The practical consequence: put more rigour into defining the phase boundary up front, and keep a disciplined register of items that fall outside it.

2. Appropriations fix the clock. Funding is often authorized for a fiscal year and can lapse. "We'll get to that next quarter" may mean "we'll get to that with money that no longer exists." Sequencing must front-load the outcome the funding was appropriated for.

3. The requirement is frequently the law. Eligibility rules, statutory deadlines, records-retention periods, and public-notice obligations are not stakeholder preferences to be traded off. Discovery must separate statutory constraints (non-negotiable, cite the source) from policy choices (agency discretion) from preferences (negotiable). Conflating them is the most common discovery error in the sector, and it produces designs that either over-engineer optional behaviour or under-serve a legal obligation.

---

Recommended Approach: Fit-Gap Against the Process Library

Because Public Sector Solutions ships pre-built data models and pre-built processes, blank-page requirements elicitation is both slower and riskier than a fit-gap. The Salesforce-aligned approach runs in this order:

Why demonstrate before eliciting

Asking a licensing supervisor "what are your requirements?" produces a description of the system they have. Showing them BusinessLicenseApplication, an Action Plan for required review steps, and a Process Library template for professional licensing produces a description of the difference between what they have and what they need — which is the only part the project has to build. It also prevents the most expensive failure mode in the sector: rebuilding a standard object as a custom one because nobody realised it existed.

The Process Library rule

Salesforce delivers the Public Sector Process Library: production-ready process templates (professional licensing, food-service permitting, building permits, grant application review, and others) bundling OmniScripts, Data Mappers, Integration Procedures, document checklists, and rules. The best-practice rule is absolute and testable: clone the template into a customer-specific version and modify the clone. Editing the delivered template in place destroys the reference asset and creates an upgrade conflict the agency will pay for later.

---

Choosing a Delivery Shape

Iterative delivery is the default recommendation on the exam because Public Sector Solutions is modular by construction: LPI, Grants, Benefits, and Emergency Response are separable, and the platform's three annual releases reward getting a narrow capability into production early.

---

The Documented Design: What Actually Has to Exist

"Design and document the solution highlighting best practices" has a concrete answer. These are the artifacts:

1. Capability fit-gap matrix — every process step marked fit / configure / extend / gap, with the resolution for each gap.
2. Object and data model map — agency entity to standard PSS object, with the fields added and why. This artifact is what stops a second team from inventing Permit__c next to BusinessLicenseApplication.
3. Process and persona inventory — the processes in scope and who performs each step (developed in section 14.3).
4. Automation design — which OmniScripts, FlexCards, Data Mappers, Integration Procedures, expression sets, decision matrices, and Action Plan Templates exist, and what each is for.
5. Integration register — every external system, the direction of flow, the volume, the timing (real-time or batch), the authentication method, and the system of record for each field.
6. Security and sharing design — org-wide defaults, role hierarchy, sharing rules, permission sets and permission set licenses, guest-user access, and identity approach.
7. Decision log — every significant choice with the alternative considered and the reason. In government engagements staff turn over and administrations change; the decision log is what prevents a successor team from unpicking a design they no longer understand.
8. Non-goals — written down, agreed, and dated.

Highlighting best practices in the documentation

The documentation should not merely record what was built; it should record why it is the maintainable choice. The recurring best practices worth stating explicitly are: standard PSS objects before custom objects; declarative automation before Apex; Business Rules Engine for any rule a policy owner may need to change; cloned Process Library assets rather than edited originals; and configuration that a successor administrator can read without a developer.

---

💡 Real-World AP-222 Exam Scenarios & Case Analysis

Scenario 1: A Discovery Approach Recommendation

A county with five regulatory departments — building, health, fire, business licensing, and environmental — has awarded a fixed-scope contract to modernize permitting. Each department describes its process as unique. The appropriation covers 14 months. The partner must recommend a discovery and design approach at kickoff.

What is the right recommendation?

• Run a fit-gap against the standard LPI capability and the relevant Process Library templates, department by department, rather than five parallel blank-page requirements efforts. The departments will discover that most of what they call unique is the same lifecycle with different regulatory codes, fee schedules, and review steps — which is exactly what RegulatoryAuthorizationType, RegulatoryCode, expression-set fee rules, and Action Plans are designed to vary.
• Sequence iteratively: take one department live inside the appropriation period, then apply the proven pattern to the rest. This protects the outcome against a lapsed appropriation.
• Separate statutory constraints from local practice in the constraint register, because the genuine differences between departments are almost always statutory.
• Record the phase boundary and non-goals in writing, since the fixed-scope contract makes later scope changes expensive.

Scenario 2: The Template Customization Question

An implementation team finds that the delivered Process Library template for food-service permitting matches the county's process except for two additional inspection steps and a different fee formula. A developer proposes editing the delivered template directly "so there is only one version to maintain."

What should the architect direct?

• Clone the template into a customer-specific version and make the two changes there. Editing the delivered asset in place forfeits the reference copy and creates conflicts when Salesforce updates the library.
• Implement the additional inspection steps as Action Plan items rather than as new custom objects, and the fee difference as a Business Rules Engine expression set so the county's finance owner can revise it when the fee ordinance changes.
• Record both decisions, with their alternatives, in the decision log — this is precisely the kind of choice a successor team would otherwise reverse.

Scenario 3: Documentation Handover

Twelve months after go-live, the agency's original project sponsor and lead administrator have both left. A new administrator asks why constituent records use Person Accounts and why eligibility logic lives in expression sets rather than in Flow.

What artifact should answer that, and what does its absence cost?

• The decision log, supported by the object and data model map. Person Accounts are a one-way, org-wide enablement, and expression sets were chosen so that a policy owner could version an eligibility rule without a release; both are decisions a newcomer would otherwise be tempted to reverse.
• Without that record, the successor team re-litigates settled architecture, and in the Person Accounts case may attempt something that cannot be undone. This is why the exam treats documentation as an implementation best practice, not as project overhead.