The moment arrives when an HR ops manager needs to add a required field to an onboarding form, change which manager tier gets a specific alert, or tweak a PTO accrual rule for a new employee class — and discovers that doing it means filing a ticket with ADP support, waiting days, and possibly paying a change fee. The job is small. The friction is enormous.
This gap persists for a structural reason: ADP and similar vendors make real money on professional services. Every configuration hour billed is revenue. There is no incentive to make customization self-serve when locked configuration is a profit center. The users who suffer most — HR coordinators and ops managers — rarely have enough organizational weight to force a vendor contract renegotiation. So the complaint sits in G2 reviews instead of getting fixed.
What makes this painful in practice, per the complaints: 'customization often requires ADP support or comes at extra cost,' 'security levels are not flexible,' 'all features are not customizable,' and 'when customized it can create errors in software function.' The last one is telling — even when users find workarounds, the system isn't designed to absorb them gracefully.
A configuration management layer that sits between the HR admin and the ADP tenant — letting them define field-level rules, routing logic, and display conditions through a visual editor, then pushing those changes via ADP's own API surface — removes the support ticket entirely for the 80% of changes that are structurally possible but artificially gated.
This is a business and not a feature because the need recurs every time headcount changes, a new location opens, a compliance requirement shifts, or a manager asks for a tweak. HR teams touch configuration monthly, not once. And because ADP has no incentive to build this themselves, the gap is structurally stable — it won't get quietly patched away.
What to build
Build a web app that authenticates against ADP Workforce Now via OAuth, exposes a visual rule editor for field visibility, conditional logic, and notification routing, and writes changes back through ADP's API — logging every change with a rollback option so HR admins can self-serve configuration without opening a support ticket.
Where to start
Start with onboarding form configuration specifically — it's the highest-frequency customization request, it has a clear before/after (new hire sees wrong fields or missing required ones), and the pain is felt immediately when a new hire cohort starts, giving you a repeatable demo moment.
The hard part
ADP's API surface is uneven — some configuration endpoints are well-documented, others don't exist, which means you'll hit a hard ceiling on what's actually changeable programmatically and will need to be honest with early customers about which customizations are in scope.
How it makes money
Monthly subscription per ADP tenant, tiered by number of active configuration rules or number of HR admin seats using the editor — roughly $200–$600/month depending on company size, with a one-time setup fee for the initial API connection and audit of existing config.
See the evidence. The complaints behind this idea, the products they came from, and similar ideas in Core HR.
More ideas in Core HR