> 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/cc-settings-nodes.md).

# Use shared settings data in Dialogue Studio

Use Dialogue Studio shared settings data to ingest settings, read them inside the flow, and manage cache-dependent behavior safely.

Use this page when a Dialogue Studio flow needs shared settings behavior to ingest contact center settings data and read that data later in the same flow.

## Before you begin

* Confirm which settings source the flow should use.
* Confirm that the settings owner, refresh owner, and flow owner all understand the same collection and item identifiers.
* Confirm that the flow has a safe path if the expected settings data is missing or stale.
* Plan to validate the ingest, read, and cache behavior in a controlled test flow before you expose it to production traffic.

{% hint style="warning" %}
Settings-driven flows depend on stable identifiers and predictable cache behavior. Confirm how the flow should react when the upstream settings source is missing, stale, or incomplete before you rely on this pattern in production.
{% endhint %}

## Separate ingest from read behavior

Keep the settings-node pattern split into two responsibilities:

1. One path ingests or refreshes the settings data.
2. Another path reads the stored data during flow execution.

That separation makes it easier to test the data source independently from the flow branch that consumes it.

## Use the ingest path to refresh shared data

Use the ingest path when the flow or environment must bring new settings data into the shared storage scope.

For a durable ingest pattern:

* configure the source endpoint or integration target
* ingest the settings update
* store the result in the expected scope
* confirm how refresh timing, polling, and full refresh behavior are handled when the source changes

## Use the reader path inside the flow

Use the reader path when later flow steps need one collection or one specific item from the stored settings data.

Before go-live, confirm:

* whether the lookup uses a fixed identifier or a value from the message or session context
* which output fields the next step expects
* what the flow should do when the requested collection or item is not available

## Keep cache behavior visible

Treat cache behavior as part of the design, not as an implementation detail to ignore.

When you use settings nodes:

* confirm the cache update or refresh expectation
* confirm how stale data is detected
* confirm how the flow behaves when the cache no longer contains the expected item
* retest the reader path after any change to the upstream settings source

## Verification

1. Confirm the ingest path can retrieve and store the intended settings data.
2. Confirm the reader path returns the expected collection or item values.
3. Confirm the next flow step receives only the fields it needs.
4. Confirm the flow reaches a safe fallback path when the upstream settings source is missing or misconfigured.
5. Confirm the cache behavior matches the refresh and update expectations for the target environment.

## Related topics

Go to **Configure advanced Dialogue Studio features** for the broader admin guidance on shared settings data and advanced feature design.

{% content-ref url="/pages/tVbNw2DZ0Mb6w6i0kFlM" %}
[Configure advanced Dialogue Studio features](/contact-center-configuration/building-your-callflow/via-dialogue-studio/configure-advanced-dialogue-studio-features.md)
{% endcontent-ref %}

Go to **Use message-flow nodes in Dialogue Studio** for the message-context patterns that can consume stored settings values later in the flow.

{% content-ref url="/pages/HxBMNdkBi7fWMOgHiMIg" %}
[Use message-flow nodes in Dialogue Studio](/contact-center-configuration/building-your-callflow/via-dialogue-studio/dialogue-manager-and-message-flow-nodes.md)
{% endcontent-ref %}


---

# 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/cc-settings-nodes.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.