CRM RECORD · SELECTED
Workflow design · Data preparation · Automation
Turning Repetitive Submissions into Repeatable Workflows
A configurable approach to repeated portal submissions: prepare data once, map each portal’s fields, and automate the form fill.
CONFIG-DRIVEN RPA · SAMPLEPortal A submission
FILLINGFIELD MAPPING
first_nameGiven name
last_nameFamily name
dobDate of birth
countryCountry
shared workflow · portal config
APPLICATION FORM 01 / 4
Switch portals to see the same workflow adapt to different field names and formats.
3,000+submissions processed
70+portal workflows configured
94%success rate
1,200+hours saved
Latest project snapshot; figures change as the platform is used. A manual submission could take about 30 minutes. Success rate is successful jobs as a share of completed jobs.
Each submission meant someone re-entering CRM details into another external portal. The same information needed different formats, and the page itself could change depending on earlier answers.
The core design question was how to support new portal workflows without adding another portal-specific code path every time.
Describe the portal. Reuse the workflow.
I designed the JSON configuration model and workflow editor so each portal’s steps and conditions could live in configuration. The shared workflow could interpret that description, while config changes could be made without redeploying the code.
One record → any portal
Make variation manageable.
Watch one record move from raw CRM data to a portal-ready run, with rules and human checkpoints visible along the way.
Stage 01 · SELECT
→
Design choices
What I built, and why.
Prepare data before the run
A Python preparation step reshapes CRM names, dates, country codes, phone numbers, and yes/no values into portal-ready values. Missing fields are surfaced before the browser starts.
Let the page determine the branch
Configuration rules check what is actually present on the page, follow relevant answers, and skip questions that do not apply. This lets one workflow cover multiple form paths.
Design for human checkpoints
My manager proposed human involvement for verification steps. I implemented the handoff so a person can complete an OTP or CAPTCHA and the workflow can continue afterward.
Make run status clear
Retries handle temporary slow-page conditions, while clear run-status categories guide the next step for configuration, portal, connection, and human-checkpoint events.
My contribution
Configuration and decision layer
- Designed the JSON configuration model and workflow editor.
- Built data preparation and conditional form logic.
- Implemented human handoffs, retries, and clear run-status routing.
- Contributed updates to browser automation after its initial implementation.
Team contribution
Clear ownership boundaries
A teammate built the Chrome extension and RabbitMQ component and initially implemented browser automation. My manager proposed the human-checkpoint approach and managed the work.
The outcome
A workflow that could grow through configuration.
More portal variation could be handled while keeping the shared codebase consistent. The project continues to run internally, so its metric snapshot changes over time.