Adapting to complexity with custom fields
As much as it was our mantra, Brex had outgrown our principle of “simplicity”.
For large finance teams, ERPs and HRIS systems aren’t just tools — they’re infrastructure. At companies like Uber, DoorDash, and Meta, systems like NetSuite, Workday, and SAP power workflows from card swipe all the way to year-end audit. Prior to this release, Brex only supported 5 native field integrations to ERP, and 6 to HRIS systems. We also didn't have any way to build custom fields that synced to third parties.
Almost all mature companies store data in specific fields they go beyond the basics. For example, our biggest names in the pipeline asked for client-specific codes, teams and sub-teams names, custom accounting categories, and more. You might even imagine a company wants to track if or not the employee likes pineapples on pizza at off-sites. On top of that, they wanted these values tied to approval chains, policy logic, and journal entries.
Without supporting those same fields inside Brex, enterprise adoption was contractually impossible. Financial admins weren’t going to re-architect decades of data models just to onboard a new tool. And for us, deals with customers like DoorDash, Flexport, and Uber stalled until we could prove we could integrate into their complexity.
This was less about sparkly UI and more an infrastructure challenge. I worked shoulder-to-shoulder with engineers at Brex and our partners at Merge API to design a resilient fields engine — one that could mirror complex external data sources while supporting Brex-native fields and logic:
Map all field sources:
From Brex-native fields to ERP and HRIS systems (NetSuite, Workday, ADP, Gusto, etc.), we catalogued where every value originated and where it needed to flow.Enumerate field types and metadata:
Text, numbers, booleans, lists, emails, phone numbers, static IDs, dependencies — and edge types we had to triage or delay.Audit behaviors across the board:
We codified sync rules, read vs. write capabilities, editability, field visibility, and permissioning.Anticipate failure states:
What happens if a field is renamed in Workday? What if it’s deleted in NetSuite? How do we handle mapping conflicts or stale syncs? Designing for resilience became a core part of the spec.
And of course, making sure to scrape 3rd party tools for parallel fields features had to hold the same level of diligence to ensure successful hooks to potential tools, especially when using generic API tools.
CONSISTENCY IS KING…
Modular designs reduce risk of manual misses across surfaces. Rather than noting every design permutation in our library, deliver spec using logic, like "If field is type: binary, then display…" Systematic logic meant safer implementation, more accurate QA & predictable UX.
…UNTIL IT ISN'T.
Some fields do warrant special treatment. For example, “Legal Entity” is technically a "list" type field — but it affects billing, tax, and cost center reporting. We used best judgement to break consistency intentionally, preserving business-critical logic while protecting the broader system.
CLARIFY, DON'T AVOID ERRORS
With 3rd party systems in play, we couldn’t eliminate breakages — but we could make them transparent and actionable. We surfaced the root cause (e.g. stale field values, mismatched types, broken syncs) and built in direct links to resolution. The deeper and clearer the link, the better.
This work unblocked some of the most technically rigorous enterprise customers in our pipeline — and laid the foundation for long-term automation.
Meta needed a field for “Company phone: Yes/No.” A seemingly small toggle, but it cascaded into downstream policy rules — like whether an employee qualified for a phone bill spend limit.
Uber needed hierarchical dependencies (Selecting “APAC” should only show countries in APAC), and conditional visibility (If category = Client Spend, then require “Which client?”; if not, hide the field entirely.)
When Flexport restructured departments in Workday, 2k+ vendors had to be manually re-mapped. This was catastrophic — until we shipped static field IDs to preserve continuity across name changes.
Most importantly, custom fields became the foundation for automated close — giving finance admins the control and transparency they needed to allow Brex to truly take action on their behalf. Only with carefully architected, robust data foundations that synced reliably, could we ultimately allow users to fully utilize our rule builder engine to power automated workflows across the entire product platform.
