14.3 Mapping Business Processes, Personas & Requirements
Key Takeaways
- The blueprint objective is to map and document the business process, personas, and requirements given a customer scenario — the persona set is what drives licensing, security, and channel decisions in Public Sector Solutions.
- Public sector personas divide sharply into internal staff (intake officer, caseworker, inspector, reviewer, supervisor, program administrator) and external actors (constituent, business applicant, grant reviewer, partner agency, volunteer).
- Every external persona forces three explicit decisions: authenticated or guest access, which Experience Cloud license type, and what the sharing model exposes to them.
- Process mapping in government must capture the statutory clock, the hand-off between departments, and the decision points where a determination becomes appealable — those are where Action Plans, Business Rules Engine, and audit evidence attach.
- A requirement is only mapped when it names the persona who performs it, the process step it belongs to, the object it acts on, and the evidence it must leave behind.
14.3 Mapping Business Processes, Personas & Requirements
Exam Focus: The blueprint objective reads "Given a customer scenario, map and document the business process, personas, and requirements." On the exam this rarely appears as an abstract methodology question. It appears as a scenario that names several actors — a constituent, an inspector, a partner agency, an external grant reviewer — and asks which configuration serves them. Getting the persona analysis right is what determines the licensing, the channel, the sharing model, and the user interface, so this objective silently drives answers across both other domains.
The Public Sector Persona Taxonomy
Government solutions have a wider actor set than commercial ones, because the agency serves people who are not its customers and works with parties it does not employ.
Internal personas (agency staff)
| Persona | What they do | What the design owes them |
|---|---|---|
| Intake officer / clerk | Receives applications and documents across channels, checks completeness | Document Checklist, Intelligent Document Workspace, fast search, queue visibility |
| Caseworker / eligibility worker | Determines benefits or program eligibility, manages the constituent relationship over time | Constituent 360 FlexCards, rules-based determination, interaction history |
| Inspector / field officer | Performs onsite visits, records findings and violations, issues enforcement | Mobile-capable assessments, Visit, assessment indicators, offline-tolerant checklists |
| Reviewer / approver | Evaluates an application against criteria, often across departments | Review and Review Workspace, Action Plans, approval processes |
| Supervisor | Manages workload, service levels, exceptions | Omni-Channel queues, operational reporting, escalation views |
| Program administrator | Owns the policy: fee schedules, eligibility rules, opportunity setup | Business Rules Engine expression sets and decision matrices they can version themselves |
| Records / compliance officer | Produces evidence for audit, appeal, and public records requests | Field Audit Trail, Document Scan Results, decision explainability |
External personas
| Persona | Relationship to the agency | Key design consequence |
|---|---|---|
| Constituent (individual) | Applies for permits, licenses, benefits, assistance | Person Accounts; authenticated portal; often needs Save-for-Later and multilingual support |
| Business applicant | Applies as an organization, may have multiple authorized agents | Account/Contact model with contact-to-multiple-accounts; authorization delegation |
| Anonymous public | Searches a funding opportunity, checks a permit status, reports an issue | Guest user access with a deliberately narrow sharing model |
| External reviewer / panelist | Scores grant applications without being an employee | Experience Cloud access to a Review Workspace; conflict-of-interest handling |
| Partner agency | Another government body sharing part of a case | Cross-agency sharing design; rarely full internal licences |
| Volunteer / responder | Supports an emergency response operation | Short-lived, high-volume access provisioned quickly then withdrawn |
The three questions every external persona forces
- Authenticated or guest? Anonymous status lookup and opportunity discovery are guest-user use cases; anything that touches personal data is authenticated.
- Which license? Experience Cloud license selection follows from expected volume and login pattern, and it is a costed decision in a government budget, not a technical afterthought.
- What can they see? Guest access in particular demands an explicitly restrictive sharing model, because a permissive org-wide default plus a public site is how constituent data becomes a disclosure incident.
Mapping a Regulatory Process Properly
A public sector process map has to carry four things a commercial swimlane usually omits.
1. The statutory clock. Mark every legally mandated deadline on the map: "complete-application determination within 30 days," "decision within 90 days," "appeal window of 20 business days." These become the service-level targets and the reason for automation, and they are frequently the exam's hidden requirement.
2. The departmental hand-off. Government processes cross organizational boundaries constantly — a restaurant permit needs health, fire, and building sign-off. Map whether reviews are sequential (each waits for the last) or parallel (all run at once). Converting sequential reviews to parallel is one of the largest cycle-time levers available, and Action Plans are how the parallel steps are expressed and tracked.
3. The determination and appeal point. Mark where a decision becomes legally consequential. At that point the design must be able to explain why the determination was made — which is why eligibility and scoring logic belongs in Business Rules Engine, whose decision output is inspectable, rather than buried in Apex.
4. The evidence obligation. For each step, note what must be retained: the submitted document, the reviewer's score, the inspector's finding, the notice sent. Retention periods in government are set by records schedules, not by convenience.
Notation that survives contact with stakeholders
Use a simple swimlane with one lane per persona and the object named at each step. The map should let a reader answer, at any step: who is acting, on what record, against what deadline, leaving what evidence? A map that names activities but not objects is not yet an input to design.
Writing Requirements That Can Be Built
A requirement is mapped when it carries four attachments:
| Attachment | Example |
|---|---|
| Persona | Fire department reviewer |
| Process step | Pre-occupancy review of a commercial permit application |
| Object / capability | BusinessLicenseApplication, Action Plan item, Visit |
| Evidence produced | Reviewer decision with timestamp, retained for the records schedule |
Add the source and classification from section 14.2 — statutory, policy, or preference — and the requirement is now both traceable and negotiable at the right level.
Common mapping errors the exam probes
- Collapsing distinct personas. "Users" hides that an inspector needs offline-tolerant mobile assessments while a reviewer needs a desktop workspace. The two need different designs.
- Missing the anonymous public. Teams design the authenticated journey and discover late that opportunity discovery and permit status lookup must work for someone with no account.
- Treating an external reviewer as staff. Grant panelists are usually not employees; giving them internal licences is both a cost and a security error.
- Ignoring delegation. A business applicant is frequently represented by an agent — a contractor's expediter, an attorney, an accountant. If the model cannot express "this person may act for that business," the portal fails on day one.
- Mapping the process without the clock. A map with no statutory deadlines cannot justify the automation the agency is buying.
💡 Real-World AP-222 Exam Scenarios & Case Analysis
Scenario 1: A Restaurant Permit Across Three Departments
A city issues restaurant operating permits. Today, the application is reviewed by the health department, then forwarded to fire, then to building — each waits for the previous. Median time is 71 days against a 45-day statutory target. Owners frequently send their attorney to act on their behalf. The public wants to check permit status without creating an account.
Map it.
- Personas: business applicant (restaurant owner), authorized agent (attorney), three departmental reviewers, a licensing supervisor, and the anonymous public.
- Process: the three reviews are the cycle-time problem. Map them as parallel Action Plan items on the
BusinessLicenseApplicationrather than a sequential chain — this is the single change that attacks the 71-day median. - Statutory clock: 45 days, marked on the map and instrumented as a service-level measure.
- Delegation: the attorney is a contact who must be able to act for the business — model with the account/contact relationship rather than by sharing the owner's credentials.
- Anonymous public: status lookup is a guest user capability on the Experience Cloud site, with a sharing model that exposes permit status and nothing else.
Scenario 2: An External Grant Review Panel
A state arts agency recruits 40 external subject-matter experts each cycle to score grant applications. They are not employees. They must see only the applications assigned to them, must not see applications where they have declared a conflict, and must submit scores that feed an award ranking.
What does the persona mapping produce?
- The panelist is an external persona, not staff: provision through an Experience Cloud site with access to the Review Workspace, not through internal user licences.
- "Only the applications assigned to them" is a sharing design requirement, and conflict-of-interest exclusion must be enforced in the sharing and assignment model rather than by asking reviewers to look away.
- Scores feed a decision matrix so ranking is consistent and explainable when an unsuccessful applicant challenges the outcome.
- Access is cyclical: provisioning and de-provisioning per funding round is part of the requirement, not an operational afterthought.
Scenario 3: Field Inspectors With Poor Connectivity
County health inspectors visit rural food establishments where cellular coverage is unreliable. They currently complete paper forms and re-enter findings at the office the next day, which delays enforcement and loses detail.
What does the persona analysis change?
- The inspector persona's defining constraint is the field, not the office. That single fact drives the design toward mobile-capable dynamic assessments recorded against the
Visit, with checklists tolerant of intermittent connectivity, rather than a desktop console workflow. - Violations and enforcement actions must be capturable at the point of observation so the evidence carries the inspector's own timestamped finding.
- Had the map collapsed inspectors into a generic "staff user" persona, the design would have optimized for the office and reproduced the paper-to-desk delay it was meant to remove.
A city restaurant permit is reviewed sequentially by health, then fire, then building, producing a 71-day median against a 45-day statutory target. Which mapping insight most directly attacks the cycle time?
A state agency recruits 40 external subject-matter experts each grant cycle to score applications. They are not employees, must see only their assigned applications, and must be excluded from applications where they have declared a conflict of interest. What does correct persona mapping produce?
County health inspectors work in rural areas with unreliable cellular coverage and currently re-enter paper findings at the office the next day. What is the consequence of collapsing inspectors into a generic "staff user" persona during mapping?