> For the complete documentation index, see [llms.txt](https://help.tellius.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.tellius.com/tellius-6.4/kaiya/tellius-mcp-server/using-connected-systems-in-kaiya.md).
# Using connected systems in Kaiya
### **Connect your account**
You connect your own account from the Kaiya conversation.
1. In the Kaiya composer, select **Connected apps** (the icon beside the attachment button).
2. The list shows every system your administrator has turned on, each with a switch. A switch that is on shows a system you have connected.
3. Turn on the switch for the system you want, and sign in to that system when it asks.
A few systems ask for more when you sign in:
* **Notion** asks you to choose your workspace and share the pages Kaiya may use. Kaiya sees only the pages you share.
* **Salesforce** signs you in at login.salesforce.com, or at test.salesforce.com for a sandbox org.
**Google Workspace** shows a separate switch for each Google product your administrator has turned on, such as Gmail, Google Drive or Google Calendar. Turn on only the products you want Kaiya to use.
### **Ask Kaiya about a connected system**
Ask in plain words and name the system. For example:
* *"What's on my Google Calendar for the next three days?"*
* *"Search Slack for recent messages about the product launch."*
* *"List my open opportunities in Salesforce."*
Reading from a connected system doesn't need your approval. Kaiya calls the system and answers. An answer that uses a connected system cites it, so you can see what was called and what came back.
{% hint style="info" %}
Not sure what's connected? Open **Connected apps** in the composer, or ask Kaiya, *"Which systems do I have connected?"*
{% endhint %}
### **Make a change in a connected system**
Kaiya can make changes for you, such as drafting or sending an email, creating a calendar event, posting to Slack or adding rows to a Snowflake table. In the conversation, Kaiya never makes a change without asking.
1. Ask for the change, for example *"Draft an email to the regional leads with these three numbers."*
2. Kaiya shows the exact change it is about to make: the account it will use, the action, and every value it will send. For an email, that means the recipient, the subject and the body. For a warehouse change, it shows the exact statement.
3. Approve the change to run it, or decline it.
Keep in mind:
* **One approval covers one change.** It runs once, exactly as shown. If anything differs from what you approved, nothing is sent and Kaiya asks again.
* **Approvals expire.** An approval you don't use within a few minutes lapses.
* **Declining changes nothing.** Kaiya tells you what was left unchanged and doesn't try again for that request.
* **Writes can be switched off.** If **Allow writes** is off for a system, Kaiya can still read from it but doesn't offer to change anything there.
### **Use a connected system as an input step**
Besides a SQL query against your data sources, a connected system can bring data into a Deep Insight, a Mission or an App. Kaiya calls the system and saves what comes back. The saved result becomes a step in the plan, and later steps read from it. Saving the result, rather than keeping it in the conversation, is what lets Kaiya work with a large set of records.
For example, a Mission can pull the open opportunity list from your CRM, and a later step can summarize that list or put it into an export.
{% hint style="info" %}
**Asking in the conversation or using an input step?** Ask in the conversation when you need an answer once. Use an input step in a Deep Insight, Mission or App when the analysis works on a large set of records, or when a Mission should pull fresh data from the system every time it runs.
{% endhint %}
### **Connected systems in Deep Insights**
A Deep Insight can read from connected systems as part of its analysis. For example, *"Analyze pipeline trends and cross-reference them with Slack."* See [Deep Insight](https://help.tellius.com/kaiya/understanding-ai-agents-and-agentic-flows/automated-workflows/deep-insight).
### **Connected systems in Missions**
Missions can read from and write to your connected systems. A connected-system step sits in the Mission plan beside SQL and Python steps.
* **A read step** pulls live data into the Mission every time it runs, and later SQL or Python steps can work on it. A read step only reads. If it finds no rows, it passes on an empty table and the run carries on.
* **A write step** sends results out, for example by inserting rows into a Snowflake table, posting a message or creating a record. Each step card shows what was asked, the calls that were made and whether the write succeeded.
In the Mission plan, a step that uses a connected system carries a **Connected System** badge and a chip for each system it uses. The step card also shows whose connection the step uses, **Runs as whoever runs the mission** or **Runs as the mission owner**, and whether it can write: **Read only** or **Can send and post**.
The Mission owner sets this for each connected-system step in the Mission editor. Select **Manage access** on the step to open the **Connected system access** dialog:
* **Run as:** keep **Whoever runs the mission**, the default, so the step uses the connection of the person running the Mission. Or choose **Always** followed by the owner's name, so the step always uses the owner's connection.
* **Allow it to send, post and create in these systems:** turn this on to let the step write. It is off by default, so a new step only reads.
A step can never reach more than the Mission owner can.
{% hint style="warning" %}
**In Tellius 6.4:** scheduled runs can read from connected systems but can't write to them yet. A step set to run as the owner works only when the owner runs the Mission. When someone else runs it, that step stops.
{% endhint %}
{% hint style="info" %}
**Which Run as to choose?** Keep **Whoever runs the mission** when each person should act through their own account, so the step sees and changes only what that person's account allows. Choose the owner's connection when the step must always use the owner's account, and plan for the owner to run the Mission, because in Tellius 6.4 that step stops when someone else runs it.
{% endhint %}
Describe connected-system steps in plain words, as you do any other Mission step. See [How to create a Kaiya Mission](https://help.tellius.com/kaiya/kaiya-missions/how-to-create-a-kaiya-mission).
### **Connected systems in Apps**
Apps can read data from your connected systems and write back through buttons in the App.
* **Reading.** An App can load data from a connected system while you build it. Building an App only reads. It doesn't change anything in the connected system.
* **Write buttons.** A button in the App can make a change, such as creating a record or a calendar event. Before anything is sent, the person using the App sees the exact values that will be written and confirms. One confirmation sends one change, even if the button is clicked twice.
* **Buttons that use the author's account.** A button can run under the account of the person who built the App. If that account's connection stops working, the button explains that the author needs to reconnect. Connecting your own account doesn't fix it.
* **When the outcome isn't known.** If a change takes too long, the App says the outcome is unknown. Check the connected system before you try again.
See [Kaiya Apps](https://help.tellius.com/kaiya/kaiya-apps).
### **Connected systems from Slack and Teams**
Each Slack or Teams thread with the Kaiya bot is a full Kaiya conversation. With a system connected for your account, Kaiya can also draft an email or create a calendar event from the thread. To set up the bot, see [Slack Integration](https://help.tellius.com/settings/administration/slack-integration) and [Teams Integration](https://help.tellius.com/settings/administration/teams-integration).
### **When a system isn't available**
* **Not connected.** If you ask about a system you haven't connected, Kaiya asks you to connect it. It doesn't guess at an answer. Connect the system from **Connected apps**, then ask again.
* **Turned off.** If your administrator turns a system off, Kaiya stops using it from your next message.
* **Not reachable.** If a system can't be reached, Kaiya says so and answers from everything else it has.
### **Best practices**
* **Name the system in your question.** *"Search my Slack"* or *"read my Snowflake"* tells Kaiya exactly where to look.
* **Allow writes only where your teams need them.** Leave **Allow writes** off for systems people only read from.
* **Check each change before you approve it.** The approval shows every value Kaiya will send, so read the recipient, the subject and the body before you say yes.
* **Talk to Tellius support before you build an OAuth app.** It saves a second round of setup if the app type or scopes are wrong.
---
# 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://help.tellius.com/tellius-6.4/kaiya/tellius-mcp-server/using-connected-systems-in-kaiya.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.
