Workflow Automation for Global HR Operations

overview

The project ran 6 months from kickoff to beta launch, with a public beta in month 3.

01 May Discovery & Validation
02 June Design & Engineering
03 July Beta Launch
04 September Multi-Step Launch

Team

CEO (main stakeholder), PM, 3 backend engineers, cross-functional partners from Onboarding, Time & Attendance, and Payroll (for API endpoints), Marketing (for launch).

My scope

End-to-end design, from early discovery to shipped product. I made final design decisions autonomously, with daily alignment with PM and engineering.

Challenge

The products customers were using felt built for engineers, not HR teams. During customer interviews, one phrase kept coming up, a company managing 100+ global employees told us directly:

"Rippling's workflow builder feels like it was built by engineers for engineers. We'd prefer less customization in favor of ease of use."

The core tension: HR teams think in natural language ("remind me 5 days before someone starts"), but systems need database logic and API calls. My job was to bridge that gap without dumbing down the power.

Discovery & Validation

With limited time for discovery, we ran parallel validation tracks:

With existing research

Searched Dovetail for interview findings from other product teams, analyzed use cases from the Integrations team, reviewed user transcripts where customers explicitly requested easier automation, and synthesized feedback from CS conversations about workflow pain points.

With Customers

Presented early concepts to 15 companies in Remote's Customer Advisory Board: triggers, conditions, actions, Slack and email integrations. Their feedback directly shaped which triggers we prioritized: employee start dates, time-off requests, contract changes.

With APIs

I spent time in Postman learning Remote's endpoints, Slack's API, and how different platforms handle webhooks. This wasn't just curiosity: I needed to understand what feedback states users might see (loading, errors, missing permissions) so I could design for real system behavior, not ideal scenarios.

With AI (post-MVP validation)

Built a simple agent using a custom GPT to test whether our architecture could handle complex requests. I wrote a detailed prompt with constraints matching our data model, then threw increasingly weird scenarios at it. After a few adaptations, 100% of the time, it returned a valid workflow structure. This validated our long-term vision of AI-assisted workflow creation, a post-MVP feature, and confirmed the architecture would support it when we were ready.

Try the agent

Exploration

The main automation need could break into needs. This became our mental model:

Show everything upfront

The first explorations surfaced all options simultaneously: every condition field, every operator, every action type visible at once. The intent was transparency, users could see what was possible.

What broke

In testing, users with simple needs ("post to Slack when someone requests time off") got lost in complexity they didn't need. The interface was accurate, but it communicated you need to understand all of this before you can use any of it.

Progressive disclosure

We shifted to revealing the interface step by step. You start with just "Set up trigger." Options appear as you make choices. A simple workflow stays simple. A complex one reveals more controls as you go.

What this solved

Users could build a basic automation in under 2 minutes without ever seeing a condition builder. Power users could still reach full complexity, same power, different packaging.

Language translation

One specific decision made with the copywriting team that changed everything: replacing database field names with natural language. Instead of

start_date timestamp with -5 day
        offset

, users see "5 days before employee start date."

What users say	What the system does
"When someone starts…"	Trigger — the event
"…5 days before…"	Schedule — the timing
"…if they’re in Colombia…"	Condition — the filter
"…notify their manager"	Action — what happens

What we cut for v1

The original scope included multi-step workflows and AI-assisted creation from day one. We deferred both post-launch. It meant customers like Very Good Ventures couldn't migrate their 39 Rippling workflows immediately. But it let us ship 6 weeks faster and validate real demand before building complexity. By September 2024, two months after launch, multi-step was live. The foundation we built made expansion straightforward.

Trigger and Condition modal in the workflow builder

Condition builder with a stacked And rule

Set up trigger step with schedule options

Edge Cases

Dynamic condition operators

When I discovered that certain conditions (employment country, hire type, department) had different valid operators depending on the field type, I worked with engineering to make the condition builder context-aware. It dynamically shows only valid operators for the selected field. No dead ends, no error messages for things that shouldn't be possible.

API error states

Through Postman testing, I designed for real failure states, what happens when a Slack token expires mid-workflow, when a Remote endpoint returns a partial response, when a condition references an employee record that's since been archived. These weren't hypotheticals; they were things I found in testing before launch.

{
  "error": "INCOMPATIBLE_EVENT_CHANGE",
  "message": "selected_event_schema_mismatch",
  "previous_fields": ["employee.start_date"],
  "new_fields": ["expense.amount", "expense.category"]
}

UI Components

The workflow builder required UI patterns Remote's design system didn't have yet. I designed and contributed three core components to Norma, now used by other product teams.

I didn't design the component system from scratch. I built on top of Norma, Remote's design system, which is WCAG AA compliant. That was a deliberate decision: inheriting accessibility rather than reinventing it.

Where I made explicit accessibility decisions:

Status indicators (Active, Paused, Archived) use both color and label (never color alone), Keyboard navigation works through the entire builder flow with no mouse-only interactions, and Error states include descriptive text, not just red borders.

Dashboard Cards

Cards needed to show workflow status at a glance while remaining actionable without opening the full editor. I designed cards with four states: Active, Paused, Archived, and New Workflow (empty state). Each state is visually distinct but uses the same underlying anatomy.

Condition Builder Fields

Dynamic form inputs that change available options based on upstream selections. Contributed as a pattern, not just a one-off component.

Check components documentation

Impact

Beta launched July 2024 to all Remote customers across HRIS, EOR, Contractors, and Global Payroll.

Within 3 months:

10+ triggers, 15+ action types shipped. Customers previously locked into competitor tools expressed migration interest. Three components contributed to Norma and adopted by other teams. One structured ideation session I facilitated produced a shared roadmap for future AI-assisted workflow creation, now a reference point for the team's next phase of work.