Customizing Inquiry Conversion

Converting an inquiry builds up to four records in a single click — an account, a contact, a deal, and the contact's role on that deal. Every field it carries from the inquiry onto those records is listed in a mapping table you can edit, and the fields it doesn't carry are the number-one "where did my data go?" support ticket. This article is for the administrator who has added a custom field to Inquiry and wants Convert to bring it along, or who wants to change the default contact role on new deals. After it, you'll be able to add or switch off mapped fields, change per-deal-type default roles, and understand the boundaries — the three legal targets, and the handful of things mappings don't control.

What one conversion creates

Before customizing the mapping, it helps to see what Convert actually produces. It runs as a single all-or-nothing action — if any part fails, the whole thing rolls back and no records are created.

The dialog lets you reuse existing records rather than create duplicates — "Choose Existing Account OR leave blank to create a new account." and "Choose Existing Contact OR leave blank to create a new contact." That reuse is a deliberate manual choice, not fuzzy matching. See Converting an Inquiry for the full end-user flow.

On a clean run the user sees "Inquiry is successfully converted. You are redirected to new opportunity record." and lands on the new deal. If the inquiry was already converted, or the user lacks convert rights, the dialog refuses to open and shows "Bad Request. Either the inquiry is already converted OR you do not have sufficient privileges to convert an inquiry. Please contact your system administrator." — a message admins field often enough to keep on hand.

The conversion mapping table

Each mapping is one record that says "copy this inquiry field onto this field of this target." A mapping record names the source field on the inquiry, the target field, the target object, and whether it's active. The target object is restricted to exactly three values: Account, Contact, and the deal. That's the hard boundary — you can't map an inquiry field directly onto a ticket or any other record.

REDA ships 60 of these, all active, split across the three targets: 5 to the Account, 12 to the Contact, and 43 to the deal. Because the conversion reads only active rows and reads them fresh each time, adding a row is all it takes to carry a new field — no code — and switching a row's active flag off stops a copy without deleting the record.

One row is worth highlighting: the inquiry's Move In Date fans out to three deal fields at once — Close Date, Lease Start Date, and Scheduled Move In Date. It's the clearest proof that one source field can feed several targets.

Here's the deal-bound set, grouped for readability (the shipped rows are a flat list; this grouping is just to find things):

The other two targets carry far fewer fields. The Account gets 5 — the company name (from the inquiry's Company), phone, region, and the inquiry-type and lineage breadcrumbs. The Contact gets 12 — first and last name, email, phone, mobile, the full mailing address (street, city, state, postal code, country), and a lineage breadcrumb. That's the split behind the most common conversion question: person and address details land on the Contact, deal specifics land on the deal, and only a handful of shared attributes reach the Account.

What is NOT mapped (and why users notice)

Two categories of "missing" data cause tickets, and both are by design:

• Person data never goes to the deal. First, middle, and last name, email, description, and notes map to the Contact, not the deal. The deal links to that contact instead of duplicating their details. Web and marketing attribution (how the lead found you) stays on the inquiry entirely — see Web & Campaign Attribution.
• Three fields whose help text is misleading. Maximum Allowed Offer, Commission Account, and Commission Amount read as if they map, but no mapping rows ship for them. Maximum Allowed Offer still appears on the deal because the deal recalculates it with the same formula — the value is regenerated, not copied. That's the flagship "explain the magic" answer for this article: nothing copied, yet the number is there.

What mappings do NOT control

A few conversion behaviors look like they'd live in the mapping table but don't. Each has its own home:

Default contact roles per deal type

A second, separate table decides the default role on a new primary contact — one row per deal record type. The default applies only when the role is left blank; a role someone chooses manually is never overwritten. And it applies beyond conversion: any new contact role with a blank role gets the default, because the defaulting lives at the record level, not in the Convert button.

Recipes

Carry a custom field

Stop carrying a field

Switch the row's active flag off rather than deleting it — that keeps the intent documented. It takes effect on the next conversion.

Change a default role

Edit the role value on that deal type's row in the role table. Existing contact roles are untouched; only new records with a blank role pick up the change.

A related, separate engine

You may notice other mapping tables in Setup that carry fields onto records REDA creates from a deal — tickets and settlement charges, for example. Those are a different engine and none of them source from the inquiry. Don't edit them expecting to change conversion; the tickets and billing articles own that behavior.

Worked example: carrying a custom field

Meridian Properties adds a custom Preferred Floor field to leasing inquiries and wants it on the resulting lease. The administrator creates a matching Preferred Floor field on the deal, then adds one mapping record — source: Preferred Floor, target object: the deal, target field: Preferred Floor, active. They convert a test inquiry for Aisha Rahman (move-in 1 Aug 2026, 12-month term). The resulting lease carries Preferred Floor; Close Date, Lease Start Date, and Scheduled Move In Date all read 1 Aug 2026 (the Move In Date fan-out at work); and the contact role defaults to Lessee.

A second, smaller change: the brokerage wants Property Sale deals to default the role to "Purchaser" instead of "Buyer." The administrator edits that single row in the role table — done, with no effect on existing deals.

Where to go next

1. Converting an Inquiry — the end-user flow and its prerequisites.
2. Global App Settings — the conversion-adjacent settings this article points to.
3. Configuring Duplicate & Merge Rules — the sibling advanced-admin config article.
4. Web & Campaign Attribution — why UTM data stays on the inquiry.
5. Understanding Inquiries — the record conversion starts from.

Frequently asked questions