15.1 Setting Up an Org for Agentforce Public Sector
Key Takeaways
- The Domain 2 objective is to define the correct steps and tools required to set up an org for Agentforce Public Sector — a distinct, testable sequence, not general Salesforce administration.
- Step one is always verifying licenses in Setup under Company Information: the Public Sector and OmniStudio user licenses and the permission set licenses that unlock features such as Business Rules Engine and Decision Explainer.
- Person Accounts must be enabled to model individual constituents, and it is effectively a one-way, org-wide decision — it belongs in the setup sequence, not in a later phase.
- Contacts to Multiple Accounts supports the delegation patterns public sector needs, where one person acts for several businesses or households.
- Users need both the correct permission set license and the matching permission set (or permission set group) — assigning one without the other is the most common reason a configured feature appears missing.
15.1 Setting Up an Org for Agentforce Public Sector
Exam Focus: One of the six objectives in the 36%-weighted configuration domain is "Given a business scenario, define the correct steps and tools required to set up an org for Agentforce Public Sector." This is not generic administration trivia. It has a documented order, it contains at least one decision that cannot be reversed, and its failure modes appear on the exam disguised as "the feature does not appear for my users" scenarios.
The Setup Sequence
| # | Step | Where | Why it comes here |
|---|---|---|---|
| 1 | Verify licenses | Setup → Company Information | Nothing else can be configured or assigned until the org actually has the licenses |
| 2 | Create organization-wide email addresses | Setup → Organization-Wide Addresses | Government correspondence must come from a departmental address, not a caseworker's personal one |
| 3 | Enable Person Accounts | Setup → Person Accounts | Required to model individual constituents; effectively irreversible, so decide before data exists |
| 4 | Enable Contacts to Multiple Accounts | Setup → Account Settings | Supports the delegation and multi-household relationships public sector needs |
| 5 | Assign permission set licenses, then permission sets / permission set groups | Setup → Users, Permission Sets, Permission Set Groups | Access requires both layers; one without the other silently fails |
| 6 | Optional platform enablement | Setup | Chatter feed tracking, Notes, and Salesforce Calendar for scheduling visits |
Step 1: Verify Licenses — the Step Everyone Skips
Open Setup → Company Information and confirm both user licenses and permission set licenses. Which ones appear depends on what the agency actually purchased, and the deployment mix matters:
- Public Sector user licenses for agency staff.
- OmniStudio licenses, because OmniScripts, FlexCards, Data Mappers, and Integration Procedures are the automation layer the entire solution rests on.
- Permission set licenses (PSLs) for the feature add-ons: Business Rules Engine, Decision Explainer, Intelligent Document Reader, Grants Management and Benefits capabilities where separately licensed, and the Experience Cloud licenses for external personas.
A licence gap discovered in week nine of a fixed-price government engagement is a procurement problem, not a configuration problem, and government procurement is slow. Verifying licenses first is the cheapest risk reduction available on the project — and on the exam, an option that begins "confirm the required licenses are provisioned" is frequently the correct first action.
Step 2: Organization-Wide Email Addresses
Define departmental sending addresses — benefits@agency.gov, permits@agency.gov — and associate them with the relevant profiles. Users can then send as either themselves or the departmental address, and replies land in the departmental inbox rather than an individual's. In government this is a continuity and records requirement as much as a branding one: correspondence about a statutory determination must not disappear into a caseworker's personal mailbox when they change roles.
Step 3: Person Accounts — the Irreversible One
Public sector programs serve individuals. A constituent applying for a housing benefit is not an employee of a company; there is no organization to hang a Contact from. Person Accounts merge Account and Contact into a single record for an individual, and Public Sector Solutions expects them for individual-constituent scenarios — notably for using IndividualApplication in grants and benefits.
Treat this as a design decision with three properties the exam likes to test:
- It is org-wide. Enabling Person Accounts changes the account model for the whole org.
- It is effectively one-way. Salesforce does not offer a simple disable once enabled and data exists. Decide before migration, not after.
- It coexists with business accounts. Agencies serve both individuals and organizations, so the design will use Person Accounts and business accounts with contacts — the choice is per constituent type, not global.
Step 4: Contacts to Multiple Accounts
Enable Contacts to Multiple Accounts so one contact keeps a primary account relationship plus secondary relationships to others. This is what makes the public sector's real relationship patterns expressible:
- an expediter or attorney who files permit applications for a dozen different businesses;
- a corporate officer listed on several licensed entities;
- a caregiver associated with more than one household in a benefits program.
Without it, teams resort to duplicate contact records — which then defeats the data-quality work in section 15.2.
Step 5: Permission Set Licenses, Permission Sets, and Permission Set Groups
This is where most "it does not work for my users" scenarios resolve. Public Sector Solutions delivers managed permission sets, and each one shows the included permission set license it depends on. Users need both:
User license + Permission Set License + Permission Set (or Permission Set Group) = working access
Practical rules:
- Depending on what the agency licensed, there are separate permission sets for Business Rules Engine, Decision Explainer, document processing, and other features. Feature-specific PSLs are assigned per user, not org-wide.
- Do not edit managed permission sets. Clone and customize them, or build a custom permission set alongside — otherwise the next package upgrade fights the change.
- Use permission set groups to bundle the sets a job role needs — an inspector group, a caseworker group, a grants reviewer group — so onboarding is one assignment rather than nine.
- Some features additionally require their own related-list or page-layout exposure before users see anything, which is why "assigned but invisible" is a layout problem as often as a permission problem.
Diagnosing the classic symptoms
| Symptom | Most likely cause |
|---|---|
| Feature missing entirely for everyone | License not provisioned (step 1) |
| Feature present for admin, absent for staff | Permission set license not assigned to those users |
| Permission set assigned but access still denied | The required permission set license was never assigned |
| Object accessible but a capability's records invisible | Related list or page layout not added |
| Individual constituents cannot be modelled | Person Accounts never enabled |
Step 6: Optional Enablement Worth Doing
- Chatter feed tracking for collaboration on cases and applications, useful when a determination is worked by several people.
- Notes for caseworker observations that are not structured fields.
- Salesforce Calendar for scheduling inspection visits — relevant the moment the Inspections capability is in scope.
💡 Real-World AP-222 Exam Scenarios & Case Analysis
Scenario 1: Grants Intake With IndividualApplication
An agency will accept disaster assistance applications from individual households using the IndividualApplication object in Grants Management. The admin has installed everything and built the intake OmniScript, but cannot create constituent records that behave like individuals.
What was missed?
- Person Accounts were never enabled.
IndividualApplicationin Grants Management for individual constituents depends on the individual account model. - The fix belongs in the setup sequence, not as a later change: enable Person Accounts before constituent data is migrated, because reversing the decision afterwards is not a simple toggle.
- Confirm at the same time that the agency will also serve organizations, and plan for business accounts with contacts alongside Person Accounts rather than forcing every applicant into one model.
Scenario 2: "Business Rules Engine Does Not Appear"
A program administrator has been trained to maintain fee expression sets herself. After go-live she reports that the Business Rules Engine screens are not visible, although the system administrator can see them.
What is the diagnosis?
- Visible to the admin but not to the business user points at permission set license assignment, not at the org's licensing.
- Assign the Business Rules Engine permission set license to that user, then the corresponding permission set — both layers are required, and assigning the permission set alone fails silently.
- Package this into a permission set group for the program administrator role so the next hire is one assignment.
- If screens then appear but records do not, check page layout and related-list exposure.
Scenario 3: The Permit Expediter
A city discovers that its permit portal cannot represent a common local reality: a single expediter files applications on behalf of 30 different construction companies. The admin proposes creating one duplicate contact record per company.
What is the correct setup answer?
- Enable Contacts to Multiple Accounts, giving the expediter one contact record with a primary account relationship and secondary relationships to every business they represent.
- Duplicating contacts creates exactly the data-quality problem the agency will spend the next year trying to reverse, and it breaks any attempt to see a single view of that person's activity.
- This is a setup-sequence decision precisely because retrofitting it after duplicate records exist means a de-duplication project rather than a checkbox.
An agency plans to accept disaster assistance applications from individual households using the IndividualApplication object in Grants Management. The admin has installed the solution and built the intake OmniScript but cannot model individual constituents correctly. Which setup step was missed, and what makes its timing critical?
After go-live, a program administrator trained to maintain fee expression sets reports that Business Rules Engine screens are not visible to her, although the system administrator can see them. What is the most likely cause and correct remedy?
A city's permit portal must represent a single expediter who files applications on behalf of 30 different construction companies. The admin proposes creating one duplicate contact record per company. What should the architect direct instead, and why is this a setup-sequence decision?