Projects · Case Study
Business Rules & Behaviors
HR.net's low-code metadata platform couldn't express custom runtime logic in Form's, so teams relied on the ability to insert custom JavaScript instead — until a company-wide UI migration broke that pattern. I designed and built a no-code business rules and behaviors system to replace it, which went on to become one of HR.net and Lifion's most widely used features.
The Problem
ADP rolled out a unified design system across all products, rebuilding HR.net's UI on Dojo in place of the existing jQuery & asp.net based UI. Every form's custom JavaScript — used for validation and interactions the metadata language couldn't express — broke on the incompatible API and/or wasn't supported by the new design system.
As part of the same redesign, a new "Screen" designer was created to replace the existing "Form" designer, built for the new design system's own structural and feature requirements. Screens didn't support custom scripts at all — so even setting the API break aside, custom JavaScript had no future in the new UI.
This wasn't a simple bug fix:
- Our customer SLA required free migration of existing customizations — no billable remediation.
- The new design system existed to enforce UI/UX consistency across ADP; unrestricted custom JS was the opposite of that.
The Goal
Based on Forms built for HR.net's core product features, roughly 70% of existing custom scripts handled interactions and validations; the new design system's own interaction patterns and controls already covered the remaining 30% natively. The goal was to close that 70% gap with a no-code alternative — durable under future UI changes, and without a costly one-off remediation project.
The Approach
In my own time, I designed and built:
- Business rules — composable functions with typed input/output parameters and logic blocks (variables, string/number operations, if/then/else, loops, notifications).
- Behaviors — rules triggered by UI events (click, input change, checkbox toggle), with inputs linked to UI values, constants, or system values, and outputs linked back to UI values.
This covered the interaction and validation gap left by scripts:
- Interactions — e.g., checking "Agree to terms" enables submit.
- Derived data — e.g., calculating a duration from start/end dates.
- Validation — notifications from a rule display automatically; errors on a before-save rule block the save.
Because rules and behaviors are declarative metadata rather than embedded JavaScript, they're framework-agnostic — they survived the Dojo migration, and any future one.
As part of the same effort:
- Existing forms were migrated to screens, with custom scripts manually rebuilt as rules and behaviors during that migration.
- I later extended rules and behaviors to run server-side, replacing "plugins" (.NET modules hooking into HR.net's save/read pipelines for logic independent of the UI — e.g., validation on a workflow-triggered save).
The Impact
- Became one of the core, most widely used features in both HR.net and Lifion — well beyond its original purpose.
- Behavior support extended to nearly every other metadata type across both platforms (more so in Lifion) — e.g., a dedicated business-rules stage in workflow processes.
- Reduced HR.net's dependence on custom .NET plugins; in Lifion, replaced the plugin framework entirely — none was ever built there.