10.3 Dynamic Fee Schedules, Calculation Procedures & Regulatory Pricing

10.3 Dynamic Fee Schedules, Calculation Procedures & Regulatory Pricing

Exam Focus: Financial compliance and dynamic fee calculation are central to government licensing, permitting, and code enforcement. On the AP-222 examination, candidates must understand how Public Sector Solutions structures regulatory fees, transition between legacy Vlocity Calculation Procedures and modern BRE Expression Sets, configure the core fee data model (RegulatoryTrxnFee and RegulatoryTrxnFeeItem), orchestrate end-to-end pricing pipelines across OmniScripts and Integration Procedures, and implement secure citizen portal payment integrations and transaction reconciliation.

---

Regulatory Fee Assessment in Public Sector Solutions

In private commercial enterprises, pricing models are designed for revenue maximization, competitive discounting, and dynamic surge pricing. In the public sector, fee assessment is governed by an entirely different legal framework: the Statutory Cost-Recovery Doctrine.

Under administrative law, constitutional limitations (such as California Proposition 26 or equivalent local statutes across jurisdictions), government agencies cannot levy arbitrary charges. Every fee imposed for a permit, license, inspection, or administrative service must reasonably reflect the cost of service required for the government to process, review, inspect, and enforce the regulatory authorization. If an agency charges fees exceeding the reasonable cost of regulatory operations, the fee risks being legally struck down as an unconstitutional, unauthorized tax.

+-----------------------------------------------------------------------------------+
|                    Public Sector Regulatory Fee Classifications                   |
+-----------------------------------------------------------------------------------+
|  [Base Application Intake Fee] ──> Non-refundable baseline administrative cost    |
|  [Plan Review Fee]             ──> Scaled by construction valuation or square feet|
|  [Inspection & Re-Inspection]  ──> Hourly inspector rates & risk-tier site visits |
|  [Statutory Surcharges]        ──> State mandated technology & environmental fees |
|  [Renewal & Late Penalties]    ──> Progressive surcharges based on expired days   |
|  [Sliding-Scale Equity Relief] ──> Subsidized fee reductions based on AMI / FPL   |
+-----------------------------------------------------------------------------------+

Typical Public Sector Fee Structures:

1. Base Application Intake Fees: Standard non-refundable fees assessed to cover preliminary clerical review and identity verification upon application submission.
2. Plan Review & Engineering Fees: Variable fees calculated dynamically based on project scope, architectural square footage, estimated construction valuation, or complexity coefficients.
3. Inspection & Re-inspection Surcharges: Flat or hourly fees based on the regulatory hazard classification of the facility (e.g., higher inspection fees for chemical storage facilities vs. retail boutiques), plus automated penalty fees for failed initial inspections requiring follow-up site visits.
4. Statutory & Technology Surcharges: Mandated add-on fees directed to specialized municipal funds (e.g., a $25 GIS modernization surcharge or a 1.5% State Building Standards Commission assessment).
5. Progressive Late Filing Penalties: Dynamic surcharges calculated as a function of elapsed days past a statutory renewal deadline (e.g., 10% penalty if renewed within 30 days, 50% penalty if renewed between 31 and 90 days).
6. Sliding-Scale & Equity Waivers: Income-tested subsidies where low-income entrepreneurs or non-profit organizations receive tiered fee discounts based on Area Median Income (AMI) or Federal Poverty Level (FPL) thresholds.

---

Architectural Evolution: Legacy Vlocity Calculation Procedures vs. Modern BRE

A critical historical transition within the Salesforce Public Sector ecosystem involves the migration from Vlocity Calculation Procedures to Business Rules Engine (BRE) Expression Sets.

+-----------------------------------------------------------------------------------+
|          Evolutionary Mapping: Legacy Vlocity vs Modern Salesforce BRE            |
+-----------------------------------------------------------------------------------+
|  LEGACY OMNISTUDIO (VLOCITY)              MODERN CORE PUBLIC SECTOR (BRE)         |
|  • Calculation Procedure             ──>  • Expression Set                        |
|  • Calculation Matrix                ──>  • Decision Matrix                       |
|  • Calculation Procedure Version     ──>  • Expression Set Version                |
|  • Pre-Processor / Post-Processor    ──>  • In-Line Steps / Integration Procedure |
|  • Aggregation Steps                 ──>  • Collection Formula Functions          |
|  • Proprietary JSON Metadata Engine  ──>  • First-Class Core Salesforce Metadata  |
+-----------------------------------------------------------------------------------+

The Legacy Vlocity Architecture

Prior to the introduction of core Business Rules Engine, OmniStudio utilized Calculation Procedures. A Calculation Procedure was configured across four distinct operational phases:

• Pre-Processor: An in-flight step that sanitized and restructured incoming JSON attributes prior to calculation.
• Calculation Steps: Sequential matrix lookups and mathematical formulas executed against legacy Calculation Matrices.
• Aggregation Steps: Built-in functions that looped through arrays of child records to compute sums, minimums, maximums, or averages.
• Post-Processor: Output formatting steps that reshaped calculation results into a destination JSON envelope.

The Modern Business Rules Engine Standard

While functional, Calculation Procedures operated inside managed package memory and were difficult to integrate directly with standard Salesforce tools like Flow. In modern Public Sector Solutions, Salesforce re-engineered the calculation layer directly into the core platform as Expression Sets:

• First-Class Metadata: Expression Sets and Decision Matrices are native Salesforce metadata objects, deployable via standard Salesforce CLI, Metadata API, and CI/CD pipelines.
• Visual Pipeline Canvas: Replaces dense tabular configuration with an intuitive graphical builder supporting in-canvas branching, sub-expressions, and simulator testing.
• Native Flow Integration: Can be invoked directly from Salesforce Flow via standard Flow Actions without requiring Apex bridges or OmniStudio wrappers.

[!TIP] AP-222 Exam Strategy: The AP-222 examination primarily focuses on modern Business Rules Engine Expression Sets and Decision Matrices. However, exam questions may reference legacy terms like "Calculation Procedure" or "Calculation Matrix" when describing legacy system migrations or historical managed package configurations. Candidates must recognize that an Expression Set is the direct modern evolution of a Calculation Procedure.

---

The Public Sector Solutions Regulatory Fee Data Model

Once an Expression Set calculates the required fees, the resulting financial obligations must be persisted into the Salesforce database. Public Sector Solutions provides a specialized, standard financial data model centered around two primary sObjects: RegulatoryTrxnFee and RegulatoryTrxnFeeItem.

+-----------------------------------------------------------------------------------+
|                  Public Sector Solutions Regulatory Fee Schema                    |
+-----------------------------------------------------------------------------------+
|  [Parent Application / Case Record]                                               |
|  • BusinessLicenseApplication, IndividualApplication, Case, etc.                  |
|       │                                                                           |
|       │ 1 (One-to-Many)                                                           |
|       ▼                                                                           |
|  [RegulatoryTrxnFee (Master Header)]                                              |
|  • Id                                                                             |
|  • ParentRecordId (Polymorphic Lookup to Application / Case)                      |
|  • Status (Draft, Due, Paid, Canceled, Refunded)                                  |
|  • TotalFeeAmount (Total Payable Financial Balance)                               |
|  • DueDate (Statutory Payment Deadline)                                           |
|  • PaidDate (Payment Confirmation Timestamp)                                      |
|  • PaymentMethod (CreditCard, ACH, Check, FeeWaiver)                               |
|       │                                                                           |
|       │ 1 (Master-Detail Relationship)                                            |
|       ▼                                                                           |
|  [RegulatoryTrxnFeeItem (Child Line Items)]                                       |
|  • Id                                                                             |
|  • RegulatoryTrxnFeeId (Master-Detail Lookup to Header)                           |
|  • FeeAmount (Individual Line-Item Currency Amount)                               |
|  • Comments (Human-Readable Description & Statutory Citation)                     |
|  • FeeType / Product2Id (Lookup to Standard Product Catalog Fee Schedule)         |
+-----------------------------------------------------------------------------------+

Detailed Object Breakdown:

1. RegulatoryTrxnFee (Regulatory Transaction Fee)

RegulatoryTrxnFee serves as the master fee header record. It consolidates the total financial liability for a specific regulatory transaction.

• ParentRecordId: A polymorphic lookup field connecting the fee header to its parent record. It natively links to BusinessLicenseApplication, IndividualApplication, PreliminaryApplicationRef, Case, or PublicComplaint.
• Status: A picklist controlling the financial lifecycle of the fee (Draft, Due, Paid, Partially Paid, Canceled, Refunded).
• TotalFeeAmount: A currency field representing the grand total owed by the applicant. It is typically calculated as the sum of all associated child fee items.
• DueDate & PaidDate: Critical temporal fields used to monitor compliance, trigger automated payment reminder notifications, and evaluate late filing penalty eligibility.

2. RegulatoryTrxnFeeItem (Regulatory Transaction Fee Item)

RegulatoryTrxnFeeItem represents an individual, itemized charge within the fee header. Under government accounting standards, agencies cannot simply present a single lump-sum charge; they must break down every constituent component.

• RegulatoryTrxnFeeId: A Master-Detail relationship linking the line item directly to its parent RegulatoryTrxnFee.
• FeeAmount: The exact currency amount assessed for this specific line item.
• Comments: A text field capturing the item description and statutory legal authority (e.g., "City Ordinance § 10-A: Commercial Kitchen Plan Review Fee").
• FeeType / Product2Id: References standard Salesforce Product2 records, allowing agencies to map regulatory fee line items directly to enterprise general ledger accounting codes and standard billing systems.

---

End-to-End Dynamic Pricing Orchestration Workflow

In a production Public Sector Solutions implementation, dynamic fee calculation operates across a synchronized pipeline connecting user experience, server-side orchestration, business rules evaluation, and database persistence.

+-----------------------------------------------------------------------------------+
|                    End-to-End Dynamic Pricing Execution Flow                      |
+-----------------------------------------------------------------------------------+
|  [Step 1: Citizen Intake (OmniScript)]                                            |
|    • Citizen enters: 6,500 sq ft, Class B Commercial Restaurant, Liquor Add-on    |
|                               │                                                   |
|                               ▼                                                   |
|  [Step 2: Server-Side Orchestrator (Integration Procedure)]                       |
|    • Executes in 1 single remote callout from browser                             |
|    • Action 1: Data Mapper Turbo Extract (Checks applicant prior standing)        |
|    • Action 2: BRE Action ──> Calls Expression Set: Restaurant_Permit_Fee_Set     |
|                               │                                                   |
|                               ▼                                                   |
|  [Step 3: Business Rules Engine (Expression Set)]                                 |
|    • Step A: Decision Matrix ──> Base Fee = $500, Tier Rate = $0.50/sq ft         |
|    • Step B: Formula Step    ──> Excess SqFt Fee = (6,500 - 2,000) * $0.50 = $2,250
|    • Step C: Sub-Expression  ──> Fire Dept Inspection Surcharge = $350            |
|    • Step D: Calculation     ──> State Hospitality Surcharge = $50                |
|    • Output: Array of 4 itemized fee objects; Total = $3,150.00                   |
|                               │                                                   |
|                               ▼                                                   |
|  [Step 4: Persistence (Data Mapper Load)]                                         |
|    • Creates 1 `RegulatoryTrxnFee` (Status = 'Due', Total = $3,150.00)             |
|    • Creates 4 `RegulatoryTrxnFeeItem` records linked to the header               |
|    • Links RegulatoryTrxnFee to the BusinessLicenseApplication                    |
|                               │                                                   |
|                               ▼                                                   |
|  [Step 5: Review & Checkout (OmniScript Step)]                                    |
|    • Displays itemized receipt to citizen with payment options                    |
+-----------------------------------------------------------------------------------+

Step-by-Step Architectural Execution:

1. Intake Capture (OmniScript): The applicant completes a guided application wizard. The form captures critical rating attributes: facility dimensions, occupancy classification, zoning district, and filing date.
2. Server-Side Orchestration (Integration Procedure): Upon advancing the step, the OmniScript makes a single remote invocation to an Integration Procedure. This server-side orchestrator manages all subsequent processing, ensuring no intermediate database chatter reaches the public web.
3. Policy Evaluation (BRE Expression Set): The IP invokes the Expression Set, passing the applicant payload. The Expression Set evaluates Decision Matrices and formulas, generating an itemized array of fee line items.
4. Atomic Relational Persistence (Data Mapper Load): The IP passes the calculation results to an OmniStudio Data Mapper Load:
   • Step 1: Inserts the RegulatoryTrxnFee record with Status = 'Due' and TotalFeeAmount = $3150.00, linking ParentRecordId to the BusinessLicenseApplication ID.
   • Step 2: Uses the Domain Object Field mechanism (RegulatoryTrxnFee:Id) to insert the four child RegulatoryTrxnFeeItem records in the same atomic transaction.
5. Constituent Presentation: The IP returns the newly created fee IDs and itemized amounts to the OmniScript, displaying an itemized digital invoice on screen.

---

Payment Gateway Integration Patterns & Financial Reconciliation

Once fees are assessed and persisted, the citizen must settle the obligation. Public sector payment architectures must adhere to strict regulatory standards, including PCI-DSS compliance, fund segregation, and auditability.

+-----------------------------------------------------------------------------------+
|                Payment Gateway Integration & Lifecycle Progression                |
+-----------------------------------------------------------------------------------+
|  [OmniScript Citizen Checkout Step]                                               |
|    ├── Option A: Hosted Payment Page (Redirect to State Treasury Gateway)        |
|    └── Option B: Tokenized Direct API (iFrame Token ──> IP REST Callout)          |
|                               │                                                   |
|                               ▼                                                   |
|  [Payment Gateway Processing (CyberSource / GovPay / Stripe)]                     |
|    • Citizen submits credit card / ACH credentials                                |
|    • Gateway authorizes and captures payment                                      |
|                               │                                                   |
|                               ▼                                                   |
|  [Transaction Settlement & Webhook Callback]                                      |
|    • Synchronous Redirect / Inbound REST Webhook returns:                         |
|      { status: 'SUCCESS', trxnId: 'TXN-984210', amount: 3150.00 }                 |
|                               │                                                   |
|                               ▼                                                   |
|  [Reconciliation & Lifecycle Automation (Salesforce Flow / IP)]                   |
|    • Updates RegulatoryTrxnFee:                                                   |
|      - Status = 'Paid'                                                            |
|      - PaidDate = System.now()                                                    |
|      - PaymentTransactionNumber__c = 'TXN-984210'                                 |
|    • Automatically Advances Parent Record:                                        |
|      - BusinessLicenseApplication.Status ──> 'Under Review'                       |
|    • Dispatches Automated Action Plan (Generates Inspector Tasks)                 |
+-----------------------------------------------------------------------------------+

The Two Core Payment Gateway Integration Patterns:

1. Hosted Payment Page (HPP) / Redirect Pattern

In many municipal and state governments, statutory policy mandates that payments must be processed through a centralized state treasury payment portal (e.g., NIC / Tyler Technologies GovPay, CyberSource, or Elavon):

• Mechanism: The OmniScript constructs a secure payment request URL and redirects the citizen's browser to the external gateway.
• Security Benefit: Zero cardholder data touches Salesforce servers, drastically simplifying the agency's PCI-DSS compliance scope.
• Callback: Upon successful payment, the gateway redirects the citizen back to a designated Salesforce Experience Cloud return URL, passing an encrypted authorization token.

2. Tokenized Direct API Pattern

When an agency requires a seamless, embedded checkout experience directly within the citizen portal:

• Mechanism: The OmniScript embeds a secure payment iFrame or web component provided by the payment gateway.
• Tokenization: The citizen enters credit card details directly into the iFrame. The gateway converts the sensitive card details into a single-use Payment Token.
• Server-Side Charge: The token is passed to an Integration Procedure, which executes an HTTP Action via Named Credentials to capture the charge against the gateway's REST API.

Financial Reconciliation & Automated Lifecycle Progression

Financial settlement is rarely instantaneous across all payment types (e.g., ACH/e-check transfers may take 2 to 4 business days to clear):

• Asynchronous Webhook Reconciliation: The payment gateway sends an asynchronous REST webhook or Salesforce receives an electronic bank statement file. An inbound API service or Salesforce Flow parses the payload and matches the PaymentTransactionNumber to the corresponding RegulatoryTrxnFee.
• Header Status Transition: The RegulatoryTrxnFee.Status is updated from Due to Paid, and PaidDate is populated.
• Lifecycle Progression Trigger: A Record-Triggered Flow detects that the fee has been paid. The Flow automatically updates the parent BusinessLicenseApplication status from Pending Payment to Under Review and initiates an Action Plan Template, automatically dispatching inspection tasks to field officers.

---

💡 Real-World AP-222 Exam Scenarios

Scenario 1: Mixed-Use Commercial Development Tiered Fee Assessment

A real estate developer applies for a complex commercial building permit for a 45,000 sq ft mixed-use retail and office tower. Municipal regulations mandate: (1) a base filing fee of $1,000; (2) a building plan check fee calculated at $0.85 per sq ft for the first 10,000 sq ft and $0.45 per sq ft thereafter; (3) a mandatory fire prevention plan review fee of $750; and (4) a state green building standards surcharge of 1% applied to the total fee subtotal.

How should the system architect structure the fee generation and persistence?

• Architectural Solution:
  • An Integration Procedure invokes an Expression Set.
  • The Expression Set computes: Base Fee ($1,000), Tiered Plan Review Fee ($8,500 + $15,750 = $24,250), Fire Review Fee ($750), and Green Standards Surcharge (($1,000 + $24,250 + $750) * 0.01 = $260), yielding a grand total of $26,260.00 across four distinct item lines.
  • An OmniStudio Data Mapper Load commits one master RegulatoryTrxnFee record with TotalFeeAmount = $26,260.00 linked to the BusinessLicenseApplication.
  • Simultaneously, the mapper inserts four child RegulatoryTrxnFeeItem records, each linked via RegulatoryTrxnFeeId with its respective FeeAmount and statutory Comments, ensuring complete financial auditability.

Scenario 2: Legacy Calculation Procedure Modernization with Webhook Payment Handling

A municipal water utility org implemented on legacy Vlocity uses Calculation Procedures to evaluate industrial wastewater discharge permit fees. When an applicant submits the application, payments are processed via ACH, which takes 72 hours to settle. Caseworkers currently check a bank spreadsheet manually and update the application status in Salesforce. The agency is upgrading to modern Public Sector Solutions and requires an automated, core-compliant architecture.

What modernization steps should the consultant recommend?

• Architectural Solution:
  1. Migrate the legacy Vlocity Calculation Procedure to a core Business Rules Engine Expression Set, replacing the calculation matrix with a core Decision Matrix.
  2. Update the OmniScript citizen intake flow to invoke the new Expression Set via an Integration Procedure, generating a RegulatoryTrxnFee record with Status = 'Due'.
  3. Configure the citizen checkout step using a payment gateway supporting ACH webhooks.
  4. Implement an inbound Salesforce REST Apex service or Platform Event listener to receive the gateway's asynchronous settlement notification.
  5. The automated process matches the transaction ID, sets RegulatoryTrxnFee.Status = 'Paid', populates PaidDate, and automatically advances the parent wastewater application status to In Review without human caseworker intervention.