> 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/operate/maintain-and-change/crm-service-maintenance.md).

# CRM Service maintenance

Maintain CRM Service configuration safely across supported configuration sources.

CRM Service configuration may come from Admin Portal or SharePoint-backed plugin settings and attributes, or from service YAML configuration, depending on the deployment.

Use this page to plan safe CRM Service maintenance. Do not manually remove CRM Service settings unless support instructs you to do so.

{% hint style="warning" %}
Removing or disabling CRM Service configuration can affect CRM data shown in WebAgent. Confirm the owner, rollback path, and validation steps before changing CRM Service configuration.
{% endhint %}

## Configuration sources

| Source                                            | Use                                                                                                                                 |
| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Admin Portal or SharePoint-backed plugin settings | Stores `CrmService` plugin settings and CRM-related plugin attributes that can be updated through the supported configuration flow. |
| YAML service configuration                        | Stores service configuration for deployments that use file-based CRM Service configuration.                                         |

Both configuration models can be used. Confirm the active model for the deployment before changing CRM Service configuration.

CRM Service configuration can include provider endpoints, encrypted credential values, `PluginSettings`, `PluginAttributes`, query templates, and phone-number matching settings. Treat these as environment-specific configuration values, not generic examples to copy between customers.

## Before maintenance

Confirm these details before CRM Service maintenance starts:

* which CRM Service provider is in use
* which configuration source is active for the deployment
* whether the change disables CRM Service or only updates provider values
* whether the change affects authentication, endpoints, query templates, phone-number matching, or field mappings
* which UCCs or WebAgent configurations depend on CRM Service
* who owns rollback if CRM data stops appearing in WebAgent

## Update CRM Service configuration

1. Confirm the active configuration source for the environment.
2. Confirm the provider settings or attributes that must change.
3. Confirm whether the change requires a provider owner, delivery owner, support owner, or database owner.
4. Request or perform the change through the supported configuration process for that source.
5. Allow CRM Service to process the configuration update.
6. Validate CRM data retrieval in WebAgent.

## Provider-specific maintenance checks

| Change area                   | Check before changing                                                                        |
| ----------------------------- | -------------------------------------------------------------------------------------------- |
| Provider endpoint             | Confirm the endpoint is the active production endpoint for the customer environment.         |
| Credentials or client secrets | Confirm the approved secret-handling process and rollback value.                             |
| Query templates               | Confirm the query owner, expected result limit, and validation records.                      |
| `PluginAttributes`            | Confirm which WebAgent fields or search categories depend on the mapping.                    |
| Phone-number matching         | Confirm the stored phone-number format before changing `PhoneNumberFormat` or region values. |
| Case status mapping           | Confirm the provider status values and WebAgent case-state mapping.                          |

## Disable or remove CRM Service

Do not treat manual row removal as a customer-facing removal process. CRM Service reacts to configuration updates and removal events, but the supported removal process still depends on the deployment and support model.

Before disabling or removing CRM Service:

1. Confirm that no active WebAgent workflow depends on CRM Service data.
2. Confirm whether the change should disable CRM Service temporarily or remove provider configuration.
3. Confirm rollback steps with support.
4. Apply the change only through the supported configuration process.
5. Validate that WebAgent behaves as expected without CRM Service data.

## Do not use legacy configuration paths

Do not use legacy local-folder guidance for cloud deployments. Use the current configuration source confirmed for the environment.

## Validation

After CRM Service maintenance:

1. Open WebAgent with a test user.
2. Search for a known CRM record.
3. Confirm that CRM data appears, changes, or disappears according to the intended maintenance action.
4. Check the support or operations record for the final configuration state.

## Configuration handoff

To configure or revise a CRM Service provider before maintenance, go to [CRM Service](/channels-integrations/crm-service.md) in Channels & integrations.


---

# 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/operate/maintain-and-change/crm-service-maintenance.md?ask=<question>&goal=<user_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.