CRM Data Dictionary Builder
Turn CRM field names and workflow context into a practical, assumption-aware data dictionary.
Customise & copy
Add the context you have. The prompt updates as you work.
Paste the field names, one per line, as exported from the CRM.
Describe the main workflow stages and how sales and marketing use the CRM.
Include any current definitions, examples, known inconsistencies, or guesses about field purpose.
List the teams that create or update CRM records.
Live prompt
4 fieldsCreate a documented data dictionary from the CRM field names and context below. Inputs: - Raw CRM field names: {{raw_field_names}} - Sales and marketing workflow context: {{workflow_context}} - Existing notes or purpose guesses: {{existing_notes}} - Teams responsible for data entry: {{data_entry_teams}} For every field, preserve the exact field name and provide: 1. Definition 2. Owning team 3. Workflow stage where it is created or updated 4. Good value example 5. Bad value example 6. Notes, including assumptions or unresolved ambiguity Return only a standard Markdown table with this exact header: | Field | Definition | Owner | Stage | Good value example | Bad value example | Notes | Include every supplied field exactly once. Use plain language and concrete examples relevant to the stated workflow. Do not invent system behavior, policies, or field meanings as facts. When information is uncertain, state a concise assumption in Notes. Do not request files, tools, or follow-up information.
Proof before you use it
A real example
Tested on gpt-5.6-luna on 2026-09-09
{
"existing_notes": "Lead Source should identify the first meaningful acquisition channel. Lifecycle Stage is used for lead, MQL, SQL, opportunity, and customer. Opportunity Type may distinguish new business from expansion. Expected Close Date is often left unchanged after deals slip.",
"raw_field_names": "Lead Source\nLifecycle Stage\nMQL Date\nOpportunity Type\nExpected Close Date\nCustomer Segment\nLast Contacted Date",
"data_entry_teams": "Marketing Operations, SDR, Account Executive, Customer Success",
"workflow_context": "A B2B SaaS company captures leads through webinars, paid campaigns, and website forms. Marketing qualifies leads as MQLs, SDRs qualify them as SQLs, account executives manage opportunities through discovery, proposal, and negotiation, and customer success owns closed-won accounts."
}A small ritual that works
How to use it
- 01Paste the exported CRM field names into Raw CRM field names, one per line.
- 02Describe the sales and marketing workflow in Sales and marketing workflow context.
- 03Add definitions, examples, inconsistencies, or guesses in Existing notes or purpose guesses.
- 04List the responsible teams in Teams responsible for data entry.
Why it works
The prompt gives the model a clear documentation task, four well-defined inputs, and a fixed set of columns for each CRM field. It requires exact field-name preservation, one row per supplied field, plain-language definitions, ownership and workflow context, concrete good and bad examples, and explicit notes for uncertainty. The instruction to state assumptions rather than invent system behavior creates a useful boundary between documented facts and unresolved interpretation. The variable labels, helper text, and examples also give the person completing the prompt practical guidance about what information to provide.
Where it fails
The prompt contains a direct formatting conflict: one instruction requires only a Markdown table with a specified header, while a later instruction requires a JSON value wrapped in a Markdown code block. These requirements cannot both be followed literally. The prompt also relies on the supplied workflow context and notes to establish field meaning, so sparse or ambiguous inputs can leave ownership, stages, examples, and definitions dependent on stated assumptions. Its requirement to include every field exactly once may also be difficult when raw field names contain duplicates or formatting differences, because the prompt does not define how those cases should be handled.
Customisation tips
Adapt the column requirements to the decisions the data dictionary must support. For example, add columns for data type, allowed values, record type, validation rule, source system, or review cadence when those details are available. Replace the generic workflow-stage instruction with the organization’s actual lifecycle stages and define whether ownership means the team responsible for entry, maintenance, approval, or final accountability. If consistent examples matter, provide approved value lists or naming conventions. Resolve the Markdown-versus-JSON conflict by choosing one final format and removing the competing instruction. You can also specify a duplicate-field policy, such as preserving duplicates with a note or consolidating identical names only when their context is the same.
Watch-outs
- The prompt asks for concrete examples while also prohibiting invented field meanings. Examples should therefore be grounded in the supplied workflow context or clearly labeled as assumptions.
- “Owner” and “Stage” can mean several different things. Define whether they refer to responsibility for entry, maintenance, approval, or business accountability.
- The phrase “every supplied field exactly once” does not explain how to handle duplicate raw names, blank lines, aliases, or names that differ only by capitalization.
- The prompt does not define a standard date format, controlled vocabulary, or rule for distinguishing leads, contacts, accounts, and opportunities.
Works in
Was this useful?
Submit your variation
If your version helps, it may be published with your name and a link back to you.
Want to make AI useful across your team? Explore Atul's training.