Creating a Validation Framework for Salesforce Product Teams

Creating a Validation Framework for Salesforce Product Teams

Project Overview

Job: Bellese – Subcontracted to E-Simplicity 
Industry: GovTech / Health Services
Project Type: Process Improvement
Role: Lead Designer

Project Summary

While subcontracted into a Salesforce Service Cloud project with Bellese Technologies, I noticed that the product and development teams—many of whom were new to Salesforce—were applying field validation in inconsistent ways. Some screens used “required” fields that blocked progress without context, while others used custom validation logic that confused users and increased support issues.

To solve this, I created a Field Validation Decision Framework that guided teams on when to use Salesforce’s built-in “required” setting versus custom validation messages or disabled buttons.

Problem Statement
Inconsistent Validation Patterns Creating Confusion and UX Debt

When I joined the Bellese Salesforce project, the product and development teams were still ramping up their understanding of the Salesforce ecosystem.
While highly experienced in healthcare systems and agile delivery, most team members were new to Salesforce design constraints — especially how validation and required field behavior differs across:

  • Standard Lightning Components

  • Screen Flows

  • Custom LWCs

  • Back-end Validation Rules

This created a pattern of inconsistency:

  • Some forms used the “Required” property, which blocked progress but didn’t explain why.

  • Others used custom decision logic, leading to unpredictable messages.

  • In multi-step flows, users often hit abrupt blockers or contradictory error text.

  • Different developers were applying their own approaches to “requiredness,” resulting in fragmented user experiences and maintenance headaches.

In short — validation logic was inconsistent, opaque, and not grounded in a shared design philosophy.

Insights:

The Root Problem Wasn’t Just Technical — It Was Governance.

Through design audits, team interviews, and QA walkthroughs, I discovered that:

  • Product managers were defining requirements as “make this field required” without context of user behavior or conditional logic.

  • Developers were implementing validation based on technical ease, not UX intent.

  • QA was testing against functional expectations (“does it block submission?”) but not usability expectations (“does it explain why or how to fix it?”).

In a platform where users could create, edit, or complete forms across multiple UI layers (record pages, quick actions, flows, and console sub-tabs), this fragmented approach was hurting adoption and increasing support tickets.

What the team needed wasn’t just design direction — they needed a governance framework that codified when to use native validation and when to build custom logic.

Solution:

The Salesforce Validation Decision Framework

I developed a Field Validation Decision Framework — a simple, visual guide to help teams decide when to use:

  • “Required” field settings (for always-mandatory data)

  • Custom Validation Rules or Formulas (for conditional logic)

  • Disabled Button and Custom Messaging (for human-centered guidance and accessibility)

The framework provided:

  • A decision matrix that aligned product, UX, and dev choices.

  • A consistency model for where error messages appear (inline, modal, or toast).

  • Tone and language standards for user-facing error text.

  • Accessibility guardrails (ARIA compliance, focus states, and screen reader support).

  • Example Flow and LWC patterns implementing each option.

The core principle was:

“Validation should help people complete their work — not punish them for mistakes.”

Implementation

I rolled the framework out in three parts:

  1. Team Training Sessions

    • Conducted walkthroughs with the product and dev teams to explain Salesforce validation hierarchy: Required → Custom Validation → Fault Path.

    • Used real examples from the Case Intake and Appeals workflows to demonstrate impact.

  2. Playbook Integration

    • Documented the framework in the project’s UX Governance Confluence and Design System (Figma + Mural) so it could be referenced during sprint planning.

  3. Design Reviews & Adoption

    • Embedded the matrix into the Definition of Ready for user stories:

      “Does this field need to be required, conditionally validated, or contextual?”

    • Partnered with QA to rewrite test scripts to validate user feedback behavior, not just field enforcement.

Outcomes:

Impact AreaBeforeAfter
UX ConsistencyAd-hoc rules, mixed logicUnified patterns across screens and objects
Development TimeHigh rework, unclear requirements30–40% reduction in build/test cycles for forms
Error ClarityGeneric “Complete this field”Contextual, human-readable feedback
AccessibilityMixed resultsWCAG 2.1 AA compliance baseline met
Team ConfidenceUncertain on when/where to use validationShared language and framework for decision-making


The framework also became a teaching tool for new developers joining the Salesforce team, helping them ramp up faster and reducing dependency on senior admins for every UX decision.

Reflection

Creating this framework clarified a broader truth:

When teams are new to Salesforce, consistency is design.

By defining clear rules for when to use Salesforce’s native features versus custom logic, we not only improved usability — we also created alignment between product intent, technical feasibility, and user experience.

This small but strategic artifact has since been reused in other Bellese and subcontracted Salesforce initiatives as a lightweight UX governance tool, ensuring that as systems evolve, the user experience remains stable, predictable, and humane.