In late 2022 I joined a Deloitte Digital public sector engagement as the lead developer on a digital transformation project. The challenge: replace a paper-based statutory notification process with a self-service digital form embedded in the agency’s existing Salesforce Experience Cloud community portal.
Background
Under the relevant state legislation, organisers of certain public events are required to lodge advance notice with the agency. The existing process was paper-based — forms were submitted physically or by email, then manually keyed into Salesforce. This created delays, data entry errors, and no real-time tracking for either the submitter or the agency.
Deloitte proposed an LWC-powered digital form within the existing Experience Cloud portal. The solution would capture structured user input, validate it client-side, and create custom Salesforce object records automatically.
My Role
I came in as the main developer at the implementation phase. The first step was a thorough codebase review. The portal already had a library of LWC components built for earlier forms, and the most valuable thing I did in the first week was not write code — it was map those existing component interfaces and design the new form to compose them rather than duplicate them.
Technical Implementation
The form itself is a multi-section LWC that guides the submitter through organisation and contact details, event location, timing and expected attendance, route details where applicable, and a final declaration step.
The two pieces worth generalising:
Composition over rebuilding. Several of the capabilities the new form needed already existed elsewhere in the portal as standalone components. Rather than reimplementing them, I treated them as a library — reading their public APIs, mapping their outputs onto the new form’s Salesforce custom object schema, and handling the edge cases where their data shape didn’t cleanly match what the new records needed. That saved weeks, and more importantly it kept the new form behaving identically to the rest of the portal from the user’s point of view.
Validation on both sides of the boundary. Client-side validation is a UX affordance, not a control. Anything the form relied on for data integrity was re-validated in the Apex controller before records were created. That principle is worth stating plainly because it’s the one people skip: if the browser is the only thing enforcing a rule, the rule isn’t enforced.
I’ve left the specifics of the portal’s submission controls out of this write-up deliberately.
Deployment
Change Set deployment for a portal project of this size is not trivial. I managed the process across feature branches and pull requests, coordinating with the project team to avoid conflicts during parallel development. We deployed 180+ metadata components — LWC bundles, Apex classes, custom objects, validation rules, sharing rules, and Experience Cloud configuration — without a rollback event.
Testing and Go-Live
I ran smoke and shakedown testing across the form’s full submission path, covering the happy path, validation failures, and partial submission recovery. On-site and remote demo workshops were held with agency stakeholders before go-live.
Results
The paper-based process was eliminated. Members of the public can now lodge notices directly through the agency’s community portal, with structured data landing in Salesforce automatically. Administrators have a complete, searchable record of all submissions without manual data entry.
The engagement also reinforced how important it is to understand an existing codebase before building — reusing what the portal already had saved weeks of development and kept the solution consistent with the rest of the portal experience.
Client details are generalised. This describes a public sector engagement delivered through Deloitte Digital; the agency, the portal, and its submission controls are deliberately omitted. The delivery approach, component count, and outcomes are as delivered.