The CTM (Call Tracking Metrics) integration can now also keep your Accounts records up to date. Previously, an inbound call from CTM created an Activity log and could update a matched Lead record using the CTM Field Mapping screen. Now there is a separate Accounts Field Mapping section on the same screen — when CTM delivers an inbound call, inbound text message, or chat that matches an existing Account, the fields you have mapped are written onto that Account in addition to the Activity that was already created. The mapping screen has also been polished so that fields you have already mapped clear out of the dropdown after each save, and the inbound update is careful never to overwrite a populated field with a blank value or a sentinel “zero” date.
Contents
1. Before You Start
2. Open the CTM Field Mapping Screen
3. Add an Accounts Field Mapping
4. Use a Custom CTM Field (the r1__ prefix)
5. Edit or Delete an Existing Mapping
6. What Happens on an Inbound Call
7. What Will and Will Not Be Overwritten
8. Frequently Asked Questions
9. Need Help?
1. Before You Start
You will need:
● A CRM user account with Settings access (typically an Admin or Power User role). Only users who can already see Settings → Integrations → Call Tracking Metrics (CTM) can use the Accounts mapping section.
● An existing CTM integration configured for your instance. The Accounts section appears inside an existing CTM account configuration — it is not a separate setup.
● A working VoIP / Dialer configuration with CTM as the active provider. The inbound update only fires on instances where VoIP controls are enabled. If your instance is not configured for VoIP, the mapping screen still saves your mappings, but no inbound call will actually trigger an Account update.
Access requirements: No new permission flags are needed. If you can already open Settings → Integrations → CTM, you can use the Accounts section.
Tip: Mappings are saved per CTM account configuration. If your tenant has more than one CTM account configured (rare), each one has its own mappings — open each in turn to configure them.
2. Open the CTM Field Mapping Screen
1. In the CRM, click Settings (gear icon) in the top header.
2. In the Settings menu, click Integrations.
3. Find and click VOIP Settings in the integrations list.
4. Click the configured CTM account row to open its detail view.
5. Clicked on Map calling Fields button.
You will see the existing mapping sections (Leads) at the top, and a new section titled Accounts Field Name below them. The Accounts section has its own table of saved mappings and its own + Add Mapping button.
Tip: If you do not see the Accounts section at all, refresh the page once. If it is still missing, contact Dazos support to confirm your instance is on the latest release.
3. Add an Accounts Field Mapping
1. In the Accounts Field Name section, click + Add Mapping.
2. A popup opens titled “Add Accounts & Ctm Custom Field Mapping” (the section name in the title varies depending on how your CRM labels the module).
3. Fill in the two fields:
Field | Description | Example |
Accounts Fields (left dropdown) | The field on the Account record that should receive the value from CTM. | First Name |
CTM Custom Field (right text input) — or CTM Fields (right dropdown) | The CTM payload field name whose value should be written. Use the dropdown when CTM provides the field as a standard one, or the text input for a custom CTM field. | caller_first_name |
4. Click Add.
5. The row appears in the Accounts mapping table. You will see a success notification.
6. The dropdowns automatically reset to the placeholder text so you can immediately add another mapping without clearing them by hand.
Repeat for every field you want to keep in sync
Typical fields to map:
Account field | CTM payload field | Notes |
First Name | caller_first_name |
|
Last Name | caller_last_name |
|
caller_email |
| |
Birthday (DOB) | caller_birthday | Empty / invalid dates are ignored — see Section 7. |
Important: You can map the Phone field on this screen if you want, but the inbound update does not write the phone number from this mapping. Phone numbers are handled by a separate, idempotent process to avoid duplicating contact-resolution logic.
4. Use a Custom CTM Field (the r1__ prefix)
CTM can deliver custom fields in its webhook payload. The CRM identifies a custom” CTM field by the r1__ prefix in the field name. For example, if CTM sends a custom field called r1__intake.region, you can map an Account field to it.
To add a custom mapping:
1. Click + Add Mapping in the Accounts section.
2. Choose the Accounts field on the left (e.g. Email).
3. In the CTM Custom Field text input, enter the full custom field name including the r1__ prefix — for example r1__intake.region or r1__caller.notes.
4. Click Add.
The CRM stores the mapping with the custom-field type. When you view the row in the table, the label is shown without the r1__ prefix (so r1__intake.region appears as intake.region) — but the full name is still used behind the scenes.
Tip: Custom CTM field names can only contain letters, numbers, dots (.), underscores (_), and hyphens (-). If you try to save a name with other
characters, the CRM rejects it with an error.
5. Edit or Delete an Existing Mapping
To edit a mapping:
1. In the Accounts mapping table, click the edit (pencil) icon at the start of the row. 2. The same popup opens, titled “Edit Accounts & CTM Field Mapping”, pre-filled with the existing values.
3. Change either side of the mapping and click Add to save.
4. The row updates in place — its database ID does not change.
To delete a mapping:
1. Click the delete (red trash) icon at the start of the row.
2. The row is removed from the table and the database. Future inbound calls will no longer write that field.
Important: Deleting a mapping does not roll back any values that were already written to Account records — it only stops future updates from happening for that field.
6. What Happens on an Inbound Call
When CTM delivers an inbound interaction — a phone call, a text message, or a chat — the CRM does the following, in order:
1. Resolve the caller to an existing Account record by phone match (this is the same lookup that already happened before this change).
2. If a matching Account is found AND the interaction is inbound (direction is inbound, msg_inbound, or chat) AND VoIP controls are enabled for the instance, the CRM:
o Reads your saved Accounts Field Mappings.
o Applies each mapped value from the CTM payload to the Account record.
o Saves the Account using the same save path a manual edit would use, which means any workflows or post-save automations you haveconfigured on the Accounts module will fire normally.
3. Whether or not the Account update fires, the Activity record for the inbound interaction is still created — same as before this change.
The result: when an existing patient or referral source calls in, their record gets the latest information from CTM (corrected name spelling, updated email, etc.) without anyone having to manually edit the record.
Tip: Because the update uses the standard save path, any workflow you have built that listens for changes on Accounts fields will fire when CTM updates the record. Use this if you want, for example, a Slack notification when an inbound caller’s email address changes.
7. What Will and Will Not Be Overwritten
The inbound update is deliberately conservative — it never blanks out an existing value or writes an obviously invalid one. The table below captures the rules.
CTM payload value | Existing Account value | Result |
A valid, non-empty value (e.g., "Jane") | anything | The Account is updated to the new value. |
Empty string or missing | anything | The Account is left alone for that field. Existing value is preserved. |
Birthday | anything | Birthday is not overwritten. |
Birthday | anything | Birthday is not overwritten. |
Birthday in | anything | Birthday is normalised to |
Phone-style field (any mapping whose Account field name contains "phone") | anything | The Account is left alone for that field — phone numbers are handled by a separate path. |
Outbound call or message | anything | The Account is left alone. Outbound interactions never trigger an Account update. |
VoIP controls disabled on instance | anything | The Account is left alone. The mapping screen still saves, but inbound interactions do not trigger writes. |
Important: This means you can confidently map any field you like, including ones you only want to populate occasionally. CTM payloads that lack the value simply do not touch the record — there is no risk of mass-blanking an Account.
8. Frequently Asked Questions
Q: Will my existing Leads / CallLogs mappings still work after this change? Yes. The Leads and CallLogs sections are unchanged. The Accounts section is added alongside them and uses its own internal field types so the two do not collide.
Q: Can I map the same Account field to both a standard CTM field and a custom CTM field? Yes. The save logic was changed so that the same Account field can have one standard mapping and one custom mapping without the second one being rejected as a duplicate. Each inbound payload then uses whichever mapping matches the field name CTM actually sent.
Q: What if two mappings target the same Account field — which one wins? The mapping whose CTM field name appears in the inbound payload is applied. If both are present in the same payload (unusual), the last one to be processed wins. If you have this scenario, delete one of the mappings to avoid surprises.
Q: Does the Account update fire for outbound calls? No. Only inbound calls, inbound messages, and chat sessions trigger the update.
Q: Does the Account update fire for calls that do not match an existing Account? No. The update only fires when the existing dialer resolves the caller to an existing Account. New callers continue to be handled the same way they were before this change (Activity created, no Account written).
Q: I just added a mapping but the dropdown still shows the field I picked. Is the mapping saved? This was a bug that has been fixed in this release. Mappings are saved on click of Add, and the dropdowns now reset to placeholder after every successful save. If you still see the field selected, refresh the page once.
Q: A user told me their date of birth got overwritten with 12/31/1969. Why? That is the bug this release fixes. 1969-12-31 is the Unix epoch zero — many systems emit it when a date field is empty. The CRM now treats this date (and 0000-00-00, 00-00-0000, and blank) as “no value” and leaves the existing DOB on the record alone.
Q: Does the Account update create an audit trail? Yes. The update goes through the standard save path, so the CRM’s change history records each updated field exactly the same way it would record a manual edit. Workflows that listen for changes on those fields also fire.
Q: Can I see which CTM call triggered an update? Indirectly. The Activity record created for the same inbound interaction is timestamped, so cross-referencing the Account’s change-history timestamp with the most recent inbound Activity for that caller will identify the source.
9. Need Help?
If something does not look right after this change:
1. Accounts section is missing entirely — refresh the page. If still missing, contact Dazos support.
2. Inbound call did not update the Account — confirm: (a) it was actually an inbound call (not outbound or transfer-out), (b) the caller resolved to an existing Account (check the Activity record), (c) VoIP controls are enabled for your instance, (d) the field you expected to update is actually present in the mapping table.
3. Dropdown did not reset after save — refresh the page. The reset script runs after each successful save; persistent failure usually indicates a JavaScript error elsewhere on the page. Use the browser developer console to confirm and report it.
4. A specific field was written with a blank or wrong value — verify the CTM payload by inspecting the webhook log on the CTM side. Empty values from CTM should never overwrite an existing Account field; if they do, capture the payload and contact Dazos support with the Account ID and the timestamp.
5. Contact Dazos support with: the CTM integration account name, the Account ID you observed the issue on, the approximate timestamp, and the field that misbehaved. Reference ticket CRM-2587.