> 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/contact-center-configuration/building-your-callflow/via-dialogue-studio/manage-dialogue-studio-maintenance.md).

# Export and maintain Dialogue Studio flows

Export Dialogue Studio flows, keep versioned backups, and manage disable, delete, and debug-node cleanup tasks safely.

Use this page to manage routine Dialogue Studio maintenance tasks such as exporting flow content, keeping versioned backups, temporarily disabling a configuration, deleting an obsolete configuration, and reducing debug-node noise.

## Before you begin

* Confirm which **Service**, **Contact Center**, and flow are in scope before you change anything.
* Confirm who owns the backup location, repository access, and restore decision for the target environment.
* Confirm that you can validate the change in a controlled test path if the maintenance task affects production traffic.
* Capture the current production state before you disable or delete a configuration.

{% hint style="danger" %}
Export or back up the current configuration before you disable or delete a Dialogue Studio configuration. A delete action is not the same as a temporary pause, and rollback expectations should be confirmed before you use a destructive maintenance step.
{% endhint %}

## Export flow configuration

Use export when you need a point-in-time copy of one flow or of the wider configuration before a change window.

Use this pattern:

1. Open the Dialogue Studio menu and select **Export** before changing live routing.
2. Select the current flow or all flows, according to the configuration you need to preserve.
3. Select **Download** and store the exported JSON in the backup location for the environment.
4. Record the **Service URL** separately: it is excluded from the export. Handle credentials separately through your organization's secret-handling process.

{% hint style="info" %}
If your environment depends on values such as the Service URL, UCC name, customized port or HTTPS settings, persisted flow storage, or external endpoints, record those separately with the backup set so the restore owner can validate them later.
{% endhint %}

## Keep a versioned Git backup

Use a remote Git repository when you need a versioned backup history for comparison, rollback preparation, or controlled collaboration.

Keep the workflow simple:

1. Create or choose the remote repository that will hold the flow backup.
2. Connect the local Dialogue Studio flow files to that repository by using the currently supported authentication method.
3. Stage and commit the current change set with a meaningful change description.
4. Push the backup to the remote repository.
5. Use the commit history to compare versions or restore a known-good state when needed.

### Keep repository access current

Before you rely on the backup:

* confirm that the remote URL points to the intended repository
* confirm that the push and pull method is still supported in your environment
* confirm that the restore owner can retrieve the repository history during an incident

### Restore and Rebind

Export/import and Git history are different recovery mechanisms; neither guarantees recovery of the entire environment. Reverting one commit is not the same as restoring any historical snapshot. Confirm current repository authentication with the repository owner rather than using obsolete alternate credentials.

For a Dialogue Studio project connected to an Azure DevOps Git repository:

1. In the Azure DevOps repository history, identify the commit whose changes should be undone.
2. Open the commit and select **Revert**. Azure DevOps creates a branch for the revert operation by default.
3. In Dialogue Studio, select the resulting branch and use **Pull** to retrieve the revert.
4. Review the changes and check the connection settings before deploying during the approved change window.

Before deploying recovered flow content, verify the Service URL and contact-center binding using [Incoming calls](/contact-center-configuration/building-your-callflow/via-dialogue-studio/incoming.md). That guide covers selecting the connection, saving, deploying, and making a controlled call to check the intended queue and exit. Keep export, restore, rebinding, and runtime validation distinct.

## Disable a configuration temporarily

Use temporary disablement when you need to stop a configuration from handling traffic without removing it permanently.

Before you disable a configuration:

1. Confirm why the configuration must stop handling traffic.
2. Confirm which bindings, triggers, or dependent flows are affected.
3. Confirm how the service should behave while the configuration is disabled.
4. Record who will re-enable the configuration and under which condition.

Use this path when the expected outcome is a reversible pause rather than removal.

To temporarily switch traffic away from a Dialogue Studio incoming-call configuration in Dialogue Cloud Neo (Connect):

1. Open the **Incoming call** node in Dialogue Studio.
2. Set **Enabled** to **Disabled**.
3. Save the node.
4. Deploy the flow.

Use this only for Connect environments where the contact center can fall back to the SharePoint IVR. Do not use this as a Unify fallback path; SharePoint IVR is not available for Unify.

Disabling the node stops that trigger from handling traffic, but unused server configuration can still be validated by Dialogue Studio. If the server configuration is obsolete, plan a separate permanent removal instead of treating disablement as cleanup.

## Delete a configuration permanently

Use deletion only when the configuration is no longer needed and the owner has confirmed that no dependent routing path should remain active.

Before you delete:

1. Confirm that a current export or backup exists.
2. Confirm that no active flow, binding, or operational process still depends on the configuration.
3. Confirm the post-delete validation owner and rollback expectation.
4. Carry out the delete action only after the approved change window starts.

## Reduce debug-node noise

Debug nodes are useful during design and troubleshooting, but they can create unnecessary noise when too many remain active in an environment that is already stable.

Use a cleanup pass when:

* the flow has moved from design into a stable operational state
* the active debug output no longer supports an open troubleshooting task
* you need to reduce noise before broader validation or support handoff

Prefer a bulk-disable workflow over one-by-one node edits when the environment supports it.

To disable all debug nodes at once in the Dialogue Studio UI:

1. Press **Ctrl + Shift + P** to open the action view, or open the menu in the top-right corner and select **View** > **Action List**.
2. Search for **Deactivate All Debug Nodes**.
3. Select the action.
4. Click **Deploy** to apply the change.

## Verification

1. Confirm the export or remote backup can be located by the restore owner.
2. Confirm the maintenance action affected only the intended flow or configuration.
3. Confirm the service behaves as expected after a disable or delete action.
4. Confirm active debug output is reduced without removing information that an open investigation still needs.
5. Record the change window, backup location, and any follow-up restore or re-enable decision.

## Related topics

Go to **Troubleshoot Dialogue Studio** for payload-shape, connection-ownership, and runtime-error investigation patterns.

{% content-ref url="/pages/1DZ33M6NXFEl7w5wpxlG" %}
[Troubleshoot Dialogue Studio](/contact-center-configuration/building-your-callflow/via-dialogue-studio/troubleshoot-dialogue-studio.md)
{% endcontent-ref %}

Go to [Manage Dialogue Studio deployment](/platform-administration/provisioning/provisioning/configurations/manage-dialogue-studio-deployment.md) when the maintenance action changes customer-visible access, authentication settings, bundle/update planning, or a provisioning boundary that must be coordinated before production change.


---

# 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/contact-center-configuration/building-your-callflow/via-dialogue-studio/manage-dialogue-studio-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.