How do we define a system for defining data relationships at scale?
ABOUT
HRIS Admins in Lattice manage a wide range of employee data across multiple product surfaces: fields, policies, workflows, and integrations.
Many of these fields are not independent. For example:
Work location determines currency, tax fields, policies
Job architecture determines compensation bands, review cycles
Department can influence cost centers, access, and more
Previously, these relationships were managed manually which created for:
inconsistent data
repetitive work
constant risk of human error
As we move upmarket, this becomes more critical given larger customers need data consistency at scale, not manual maintenance.
CHALLENGE
The challenge wasn’t just designing conditional logic, it was scoping it.
Admins needed flexibility, but supporting full rule complexity introduced issues like conflicting logic, unclear evaluation, and unpredictable behavior at scale.
We had to decide:
What is the smallest version of this system we can build that still feels useful, without creating long-term complexity we can’t support?
PROCESS
Auditing fields & intended behaviors
To get an understanding of underlying data and relationships, I audited:
what inputs exist (e.g., work location, department)
what outputs are affected (fields, options, defaults)
how rules are applied and propagate
where ambiguity or conflict could occur
This helped define constraints early and avoid designing something that would behave unpredictably.
2. Flexibility vs. system constraints
Through discovery, we learned that an ideal system would allow multiple conditions. For ex., a small set of inputs like location, employment type, and job info typically determine downstream data across other products like what time off policy you’re assigned or what compensation band you’re in.
But this introduced significant complexity and eng scope. We would have to consider evaluation order, performance concerns, and nuanced behaviors.
We scoped the first version down to:
single-variable conditions (Field A → Field B)
deterministic rule evaluation
3. Define how logic should be modeled (Groups vs Fields)
A key decision was how admins should define conditional logic:
Groups-based model → Defined logic using pre-defined collections of users that admins can create
Field-based model → Define logic directly on field values (e.g., Work Location → EIN)
4. Validate mental models through research
We tested the Groups vs fields and gathered key insights:
Groups have decent usage but fairly inconsistent intent
Admins mostly preferred thinking directly in field relationships
Groups introduce long-term risk:
overlap of employees
maintenance overhead when employees join/attrit
unclear ownership
This shifted the direction toward a primarily field-based model with a secondary milestone addressing groups.
5. Design for legibility and trust
A core principle was to be predictable so we designed the experience to:
clearly show condition → outcome relationships
allow admins to preview changes before committing
indicate when fields are system-driven (locked states)
provide confirmation when changes affect multiple users
Because small changes could impact large datasets, clarity was critical.
TRADEOFFS
System Completeness vs Iteration Speed
A more complete solution would have been Dynamic Assignments: a system where a few inputs drive everything downstream. Instead, we shipped Conditional Fields as a smaller step.
Why: The full system introduced significant complexity and risk. Shipping a constrained version allowed us to validate patterns and move toward the larger system incrementally.
Groups vs Fields
Admins can define logic using groups or directly on fields. Groups allow more flexibility, but introduce abstraction and maintenance overhead. I chose a field-based approach where relationships are explicit.
Why: Admins' mental models typically point to field relationships. And groups usage is inconsistent.
Power vs Safety
Admins are power users, but small changes can impact hundreds of employees. I added validation, previews, and confirmation steps before changes are applied.
Why: This workflow is low-frequency but high-impact.
Configuration vs Maintenance
Defining rules is relatively easy, but understanding and maintaining them over time is harder. I focused on making relationships easy to read and review, not just create.
Why: The long-term cost of a system is in maintaining it. Poor visibility leads to confusion, duplication, and loss of trust.
IMPACT
Reduced manual data entry for admins → admins can define rules once instead of maintaining dependencies manually
Improved data consistency across employee records → fewer mismatched or incomplete field values
Established a foundation for future system expansion → Conditional Fields informed the direction toward Dynamic Assignments
