Sector exploration · Grants distribution
Grants distribution.
A B2B2C sector study.
Grants distribution touches multi-party funding, regulatory compliance, consumer applications, and B2B partner networks. We built a working model to understand how the pieces fit: data model, API contracts, auth, tenant isolation. The UI is a skin. The logic underneath is where the work went.
Context
The interesting problem
Grant-funding organisations (utilities, councils, housing associations) distribute funds to households through intermediary platforms. The platform serves two different user groups: partners managing money and placing orders, and applicants submitting and tracking claims.
The starting question
Salesforce is a natural fit for case management: applicant lifecycle, triage, assessment workflows. But the B2B partner side (fund management, ordering, catalogue, reporting) doesn't sit well in Experience Cloud. What happens if you give each side the platform that suits it, and connect them through API contracts?
The split works
Salesforce handles applicant flows, AI-assisted triage, and assessor tooling. A lightweight serverless stack handles partner self-service with tenant isolation. The integration boundary is clean.
Where the effort went
Data model, API contracts, authentication, tenant isolation, governance. We started with identity and data ownership because those are the foundations hardest to change later and most important to own. The frontend is deliberately simple. It's a theme on top of the logic, and themes are infinitely editable. Flows and upstream integrations are pluggable. The building blocks underneath are what matter.
What's here
A deployed system with seeded data, recorded walkthroughs, and documented architecture decisions. Not a mockup. The logic runs, the auth is real, the data flows end-to-end.
What was built
Two platforms, one integration boundary
Salesforce for the applicant side: case management, triage, assessment. A custom portal for partners: fund management, ordering, reporting. Connected through API contracts, not point-to-point wiring.
Applicant lifecycle
Custom objects, 8 automated flows, screen flows for submission, Named Credentials for secure callouts. Full lifecycle from application to award.
Triage & summarisation
Applications summarised via Anthropic API through an Apex queueable. Assessors see a plain-language summary alongside the raw data. Faster decisions, better consistency.
Partner self-service
Dashboard, fund management, product catalogue, order placement, reporting. Plain HTML/JS/CSS, no framework, no build step. The UI is a skin; the API layer does the work.
API & data layer
7 OpenAPI contracts. Python Lambda handlers. DynamoDB single-table design. HTTP API Gateway with JWT authorisation. Tenant-scoped at every layer.
Security & compliance
PKCE auth. Tenant isolation via JWT claims. GDPR-annotated data model. Opt-in consent. Delivery addresses masked post-fulfilment.
Cloud-agnostic patterns
Currently on AWS (Lambda, DynamoDB, Cognito, CloudFront, EventBridge, SQS). The patterns (serverless compute, document store, managed auth, CDN) are portable. We used what was there.
Application lifecycle
Submission to award, one human decision
An applicant submits through the Experience Cloud portal. Salesforce flows handle every status transition. The assessor drives the decision. AI-generated summaries, record history, and cross-referral flags give them context, but the judgement is theirs.
Consent is opt-in. Cross-referral sharing and evidence reuse both default to "no". The applicant opts in explicitly. Aligned with GDPR Article 7.
Assessor workflow
The human in the middle
Between submission and award sits an assessor: the person who reviews applications, checks eligibility, and makes the decision. The system does the legwork: an AI-generated summary surfaces key circumstances, flags cross-referral matches, and prepares a recommended action. The assessor reads, decides, and moves on. One human step in an otherwise automated chain.
AI triage summary
Each application is summarised via Anthropic API. Plain-language overview of circumstances, urgency indicators, and any cross-referral matches from other funds.
Assessment tooling
Salesforce screen flow. The assessor sees the summary alongside raw data: evidence, consent status, applicant history. Award or reject with a reason code.
Notifications
Award triggers an email to the applicant and an event to the partner's fund balance. Rejection triggers a different template. Both are flow-driven, not manual.
B2B partner portal
Partner self-service
In a grants programme, each partner organisation needs portal access. Most CRMs handle this through community or partner licences (per-seat or per-login), scaling linearly with the number of organisations. Costs vary widely depending on volume, licence tier, and negotiated terms, but for comparison: 200 partners on a mid-tier community licence might run $36k–60k a year at list. This portal sidesteps that model. Six screens cover the full partner workflow (funds, orders, outcomes, reporting) with authentication handled by a managed identity service and access control enforced at the API layer. Infrastructure costs grow with usage (storage, compute, bandwidth) but not linearly per seat, and without the licensing breakpoints.
Dashboard
Balance, 30-day spend, pending orders, utilisation chart. Low balance alerts. Onboarding empty states.
Fund Management
Load funds via invoice/BACS or card. Transaction history with running balance. Date range filtering.
Orders
Browse catalogue. Build order. Beneficiary details. Cancel with reason. Event timeline per order.
Reports
Fund utilisation by category. Outcomes by postcode. CSV download. Ofgem export format.
Snippets from automated journey testing
Recorded Playwright journeys
Playwright tests run against the live environment with seeded data. Each clip is a journey test recording, not a screencast.
01
AI-Assisted Triage
An assessor opens application GP-0013. An AI-generated summary surfaces the key circumstances, flags a cross-referral match, and prepares a recommended action. The assessor decides.
02
Placing an Order
A partner admin selects a product, assigns it to a beneficiary, and confirms. The order timeline updates in place: placed, then processing.
03
Role-Based Access
Admin and viewer in the same tenant. Full navigation vs. a restricted view. Same portal, different permission set. Enforced at the API, not the UI.
04
Reports & Audit
Fund utilisation, spend-to-date, remaining balance, 30-day trend, outcomes by postcode district. CSV export for the fund manager's own records.
05
Three Partners, One Platform
Same URL, three separate organisations. Each sees only their own data. Tenancy is enforced at the API layer via JWT claims. The frontend has no concept of other tenants.
06
The Applicant
A household applying for an energy hardship fund. Magic link sign-in, application status, evidence upload, consent management.
Architecture
How the pieces connect
Salesforce owns the applicant lifecycle. The serverless stack owns partner operations, fund management, and the API layer. The two meet at a clean integration boundary: Named Credentials on the Salesforce side, API Gateway on the other.
Getting the data model, identity layer and API contracts right first is what makes everything else straightforward: reporting, automation, regulatory compliance, and configuration-based expansion across new schemes and partners. The fundamentals carry the weight.
How this was built
One developer. Two AI-assisted IDEs sharing the same workspace and context. Spec written before code: requirements, data model, API contracts, infrastructure design. Decisions documented as ADRs.
Stack detail
Services used
Currently deployed on AWS. The service choices map to generic patterns (serverless compute, document store, managed auth, CDN, event bus, queue) that would work on other clouds with equivalent services.
| Service | Role | Pattern |
|---|---|---|
| DynamoDB | Single-table design, 4 GSIs | Document store |
| Lambda | Python 3.12 handlers + auth endpoints | Serverless compute |
| API Gateway | HTTP API with JWT authoriser | Managed API gateway |
| Cognito | User pool, PKCE, groups, custom attributes | Managed auth |
| CloudFront + S3 | Portal assets, security headers, SPA routing | CDN + object storage |
| EventBridge | Order events, fund alerts, daily reconciliation | Event bus |
| SQS | Order processing queue with DLQ | Message queue |
| SSM Parameter Store | All secrets and configuration | Config / secrets store |