Data entry automation template
This template moves data from forms, emails and documents into a system of record. It validates every field, sends changes to existing records to a person, and reads each record back after writing it.
Last reviewed 7 October 2026
Starting point
The status rests on the workflow salesforce-lead-workflow, which creates a record in Salesforce and fetches it again. As shipped it writes one fixed test lead, so the source, the field mapping, the checks and the review are yours to build.
The library has a template, chatflow, MCP server or governed template that covers part of the job. You assemble the rest in Studio.
What this template does
Data entry is owned by whichever team lives with the data: sales operations for leads, finance for suppliers, support for tickets. The work is retyping. Information arrives in one shape and has to leave in another, and a person bridges the gap.
By hand the errors are small and costly. A phone number loses a digit, a name is entered twice, a new value overwrites a good one. This flow writes new records automatically only when every check passes, sends anything that would overwrite an existing value to a person, and reads each record back to confirm it says what was meant.
The workflow, step by step
Steps marked as approval gates pause the run until a named person approves. Nothing after a gate runs before that decision, and the decision is recorded.
- 01
Receive the source
A form submission, an email or an attached file starts the run. The workflow stores the original untouched with its source and arrival time and passes the content on. Attachments are read to text where needed, so the next step receives text plus a pointer to the original. - 02
Extract the fields
A model maps the content to your target fields and marks each one found, missing or uncertain. Values it cannot find stay empty and are never filled by guesswork. The next step receives a record in the target schema together with the marks. - 03
Check against your rules
Code steps test formats, such as email shape, phone length and country codes, and the required fields. A lookup in the target system finds likely duplicates by email or name. The result is a list of passes and failures attached to the record. - 04
Route by risk
A branch separates two groups. A new record that passed every check and matches no duplicate goes straight to writing. Anything that failed a check, looks like a duplicate or would overwrite an existing value goes to review with the reason attached. - 05
Review the proposed change
The run pauses for the data owner named for that record type. They see the source beside the proposed change, field by field, and accept, edit or reject. An accepted overwrite is recorded with the old value and the new one, so it can be reversed by hand.Approval gate: a named person approves before the next step runs. - 06
Write and read back
The workflow creates or updates the record in the target system, then fetches it again and compares each field with what it meant to write. A mismatch raises an alert and holds the run open. A match closes it, and the source, checks, review decision and read-back result are stored under one reference.
What it can do, cannot do, needs approval for, and records
Can
- Read forms, emails and attached files into your schema
- Validate formats and look for likely duplicates
- Create records that pass every check
- Read each record back and compare it with what was meant
Cannot
- Fill a field it could not find
- Overwrite an existing value without review
- Delete a record
- Change the validation rules during a run
Requires approval
- Any overwrite of an existing value, by the data owner
- Records that failed a check or look like duplicates
- Changes to the field mapping, by the process owner
Records
- The original source and its arrival time
- The extracted record with found, missing or uncertain marks
- Check results and the route taken
- Old and new values for each accepted overwrite
What the library holds for this job
| Asset | Type | Covers | Role in this flow |
|---|---|---|---|
| Salesforce Lead Workflow | Workflow template | Part of the job | Queries leads, builds a lead from fixed test values, creates it in Salesforce, fetches it back and checks that it has an Id. It supplies the write-then-read-back pattern. |
| Extract Key Information from Text | Prompt | Used inside the flow | A starting prompt for mapping free text to named fields. |
| Salesforce | Integration | Used inside the flow | The system of record in the shipped workflow. |
| Hubspot | Integration | Used inside the flow | An alternative CRM target. |
Integrations this flow uses
- Salesforce: The system of record in the shipped workflow.
- HubSpot: An alternative CRM to write to.
- Airtable: A common target for operational tables.
- JotForm: A source of form submissions that start a run.
The full list of tools Studio connects to is on the integrations page.
What you supply, and what this page does not cover
- You supply the source, the target schema, the field mapping, the validation rules and the data owner for each record type.
- The shipped workflow writes a fixed test lead to Salesforce. Do not run it against a live account without replacing the test values.
- Screen-only applications with no API or export are outside this design. For those, see the page on RPA alternatives.
- Whether you may process the personal data in a source, and where, is a decision for your data protection lead. This page is not legal advice.
Common questions
- Will it write to my CRM without asking?
- Only for new records that passed every check and match no existing record. Anything that would overwrite a value, failed a check or looks like a duplicate waits for the data owner. You can tighten that further and send every write to review while you learn how the extraction behaves on your data.
- What does the read-back step do?
- After writing, the workflow fetches the record from the target and compares each field with what it intended to write. A difference raises an alert and keeps the run open. It catches truncated values, silently changed formats and fields the target system refused, which otherwise show up weeks later.
- Is this the same as RPA?
- No. RPA replays clicks on a screen. This flow reads content with a model and writes through an API or an integration. That is more stable when layouts change, but it needs a system with an API. If the only way in is the screen, a bot may still be the right tool.
- Can I use it with Airtable or HubSpot?
- Yes, those integrations exist in the library, and the pattern is the same: extract, check, write, read back. The shipped workflow itself targets Salesforce, so you rebuild the write and read steps for another system. The checks and the review step carry over unchanged.