> For the complete documentation index, see [llms.txt](https://atlas.anywhere.now/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atlas.anywhere.now/channels-integrations/crm-service/configure-crm-service-settings.md). # Configure CRM Service settings Understand shared CRM Service settings, attributes, request flow, and secret-handling boundaries. CRM Service uses `CrmService` `PluginSettings` and `CrmService` `PluginAttributes` to connect one CRM provider to WebAgent. Use this page as a shared reference. Configure provider-specific values from the relevant provider page. ## Before you begin * CRM Service is enabled for the environment. * The CRM Service provider is enabled for the UCC. * The provider endpoint and authentication values are approved for the environment. * You know which WebAgent or UCC configuration consumes CRM Service data. * You know the active configuration source for `CrmService` `PluginSettings` and `CrmService` `PluginAttributes`. {% hint style="warning" %} Do not store unmanaged secrets in CRM Service configuration. Sensitive values must use the approved secret-handling process for the customer environment. {% endhint %} ## Request and change model Use this pattern for each CRM Service provider: 1. Request the provider CRM Service through the current OnePortal, delivery, or support process for the customer environment. 2. Confirm which CRM provider is enabled for the UCC. 3. Prepare the CRM-side application, user, token, connector, list, database, or API access required by the provider page. 4. Confirm that the required CRM Service settings are provisioned for the UCC. 5. Enter or request provider settings through the active configuration source for the environment. 6. Validate the CRM Service endpoint, WebAgent consumption path, and CRM lookup behavior with a known test record. {% hint style="info" %} Do not rely on legacy labels for OnePortal or configuration-source navigation. Use the current labels and ownership model supplied for the customer environment. {% endhint %} ## Configuration sources CRM Service can combine default service configuration with configuration supplied through the active configuration source for the environment. Depending on the environment, updates can be owned through a portal-backed flow, delivery-owned configuration records, or service configuration. Treat YAML and backend configuration as service or delivery configuration unless customer ownership is confirmed for the environment. List-backed updates to relevant `PluginSettings` or `PluginAttributes` can reinitialize plugin configuration. ## Common configuration areas Most CRM Service providers use these configuration areas. Use the provider page to identify the exact provider-specific values, then enter or request those values in the active configuration source for the environment. | Configuration area | What it is for | Where configured | Where used | Provider-page relationship | | -------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Provider endpoint | Identifies the CRM or data source that CRM Service connects to. | CrmService PluginSettings for the provider. | CRM Service connection setup and health checks. | Each provider page names the endpoint setting or value that applies to that provider. | | Authentication values | Authorizes CRM Service to retrieve data from the provider. | CrmService PluginSettings, with secrets handled by the approved secret-handling process. Some values are created in the provider administration portal first. | CRM Service authentication when it calls the provider API or data source. | Each provider page lists the required access model, such as OAuth application values, service-account credentials, token values, or connection-string values. | | Provider behavior settings | Defines provider-specific lookup, query, case-status, attachment, or matching behavior. | CrmService PluginSettings for the provider. | CRM Service lookup/query behavior and WebAgent display behavior where applicable. | Required and optional provider settings are documented on each provider page. | | `PluginAttributes` | Maps CRM records and fields to WebAgent output, search, and display behavior. | CrmService PluginAttributes for the provider. | CRM Service field mapping and WebAgent CRM result display. | Use the provider page to decide whether default mappings are sufficient. Keep complete customer-specific mapping records in the delivery or configuration record. | | Phone-number recognition | Controls how phone numbers are normalized or matched when CRM Service searches provider data. | Usually CrmService PluginSettings, using provider-specific settings such as `DefaultPhoneNumberRegion`, `PhoneNumberFormat`, or equivalent query behavior. | CRM Service lookup/query behavior when WebAgent searches by caller or contact phone number. | Provider pages identify supported phone-number settings for that provider. | ## PluginSettings CrmService PluginSettings define provider-level values such as endpoints, authentication references, lookup behavior, and provider options. Keep provider-specific setting names, mandatory values, optional settings, and query guidance on the provider page. ## PluginAttributes CrmService PluginAttributes define how CRM records and fields are exposed to WebAgent. Common PluginAttributes categories can include: | Category | Typical use | | --------------- | ----------------------------------------------------------------------- | | `Account` | Account fields shown for matched account records. | | `AccountSearch` | Account fields used or returned during account search. | | `Contact` | Contact fields shown for matched contact records. | | `ContactSearch` | Contact fields used or returned during contact search. | | `Lead` | Lead fields shown for matched lead records. | | `LeadSearch` | Lead fields used or returned during lead search. | | `Case` | Case fields shown for matched case records. | | `Submission` | Submission fields shown where the provider supports submission records. | Enter or request `PluginAttributes` in the provider's CrmService PluginAttributes configuration record. Do not place field mappings in a provider endpoint or authentication setting. Use the customer environment's approved configuration process, or request the change through the delivery or support path when direct editing is not confirmed for the environment. Keep provider-specific attribute mappings on the provider page and in the delivery or configuration record. Do not maintain cross-provider field-mapping tables in this shared reference. ## Phone-number matching modes CRM Service provider configuration can use phone-number matching modes such as: | Mode | Use | | --------------- | ------------------------------------------------------------------------------- | | `E164` | Matches phone numbers stored in E.164 format. | | `International` | Matches phone numbers stored in international display format. | | `Rfc3966` | Matches phone numbers stored as RFC 3966 telephone URIs. | | `Wildcard` | Performs a wildcard search when stored phone-number formatting is inconsistent. | | `Pattern` | Uses a configured pattern where the provider supports pattern-based matching. | References for phone-number formats: * [ISO 3166 country codes](https://www.iso.org/iso-3166-country-codes.html) * [ITU-T E.164](https://www.itu.int/rec/T-REC-E.164/en) * [ITU-T E.123](https://www.itu.int/rec/T-REC-E.123) * [RFC 3966](https://www.rfc-editor.org/info/rfc3966) For the broader relationship between CRM Service recognition, WebAgent parsing, CTI plugin URL formatting, and callback normalization, see **Phone-number formatting and normalization**. {% content-ref url="/pages/SVfbm8qnN8jL96ZNBHiv" %} [Phone-number formatting and normalization](/channels-integrations/setting-up-integrations/phone-number-formatting-and-normalization.md) {% endcontent-ref %} ## Custom CRM Service conversation ID lookups This section applies only when a customer uses a custom CRM Service created with Dialogue Studio and the flow uses the WebAgent conversation ID as a CRM record lookup key. From DC2025.02a, the WebAgent `conversationId` URL parameter keeps the same parameter name but can contain a different ID format. Before the update, the value can be the previous hunting conversation ID, a 32-character value without hyphens. After the update, the value can be the platform dialogue ID, also known as the correlation ID, in hyphenated GUID format. These identifiers are different values and cannot be converted into each other. Before updating to DC2025.02a or higher, prepare affected custom CRM Service flows to detect both formats and route to the correct lookup behavior. Route unexpected formats to error handling instead of performing a CRM lookup with an invalid key. {% hint style="info" %} Where possible, use a stable customer key for CRM lookup behavior and store the current `conversationId` only for traceability. {% endhint %} ## Secret-handling boundaries Provider pages identify secret-bearing values such as passwords, tokens, client secrets, and connection strings. Use the approved secret-handling process for the environment. Do not prescribe a legacy password utility or local encryption procedure unless support confirms that it is the current customer-facing process for the environment. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://atlas.anywhere.now/channels-integrations/crm-service/configure-crm-service-settings.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.