# Execute Mode
Source: https://docs.rallied.ai/agents/execute-mode
Let the agent resolve tickets end-to-end: it diagnoses, executes, and only pauses for a technician or manager when an action requires sign-off.
Execute Mode is the normal operating mode for production clients. The agent handles requests end-to-end: it diagnoses the issue, decides on a plan, and executes. It pauses only when a tool's policy requires a technician (or manager) to approve first.
Every action is governed by the tool policies you configure in Rallied. You decide which operations run automatically and which ones require a human sign-off.
## The approval flow
A request lands through one of your channels: a new ticket in ConnectWise, HaloPSA, or Autotask, or a message in Slack or Teams where you've connected one. For example: "I need access to Zendesk."
The agent uses read-only tools to gather context: it looks up the employee in Microsoft 365, checks what apps they already have access to, reviews group memberships, and reads your runbooks in Hudu or IT Glue. This happens in the background; the employee sees nothing yet.
The agent always posts an internal note on the source ticket (a ConnectWise note, HaloPSA action, Autotask note, and so on) with its full diagnosis and the plan it intends to execute. Your team can see this note; the employee cannot.
For each action in the plan, the agent checks the setting you've configured:
* **Auto-approve** — runs immediately, no approval needed.
* **Needs approval** — the agent must get a technician's sign-off before running this action.
If every action is Auto-approve, the agent runs the full plan and moves to the reply step. If any needs approval, the agent pauses and creates an approval request.
When everything is Auto-approve, the agent runs the plan immediately and replies on the source ticket (or in the chat or call where the request came in) confirming what was done.
The agent creates an approval request and notifies your technicians through the configured channel (see [Approval notification channels](#approval-notification-channels) below). The agent then waits. It does not reply to the employee yet.
A technician with the `msp_technician` or `msp_admin` role reviews the plan and responds. If they approve, the agent proceeds. If they deny, the agent informs the employee that the request was not approved.
After approval, the agent executes the approved plan and replies to the employee on the source ticket, call, or chat.
## Approval notification channels
When an approval request is created, your technicians are notified through the integration your MSP has configured. PSA channels (ConnectWise, HaloPSA, Autotask) are the primary approval channels; Jira and Slack are available where you've connected them.
| Integration | Notification method |
| - | - |
| ConnectWise | Note added to the ConnectWise ticket |
| HaloPSA | Action added to the HaloPSA ticket |
| Autotask | Note added to the Autotask ticket |
| Jira | Comment added to the Jira issue |
| Slack | Direct message to technicians in Slack |
Notifications go to all MSP users with the `msp_technician` or `msp_admin` role.
## Dual approval
Some operations require both a technician and a manager to approve before the agent can proceed. You configure this per action on the integration's detail page by enabling the **Require manager approval** option alongside **Needs approval**.
When dual approval is required:
* A technician approval request is created (as always).
* A manager approval request is also created, linked to the technician request.
* **Both must approve** before the agent executes. If either party denies, the request is denied.
* The manager in question is the requesting employee's direct manager, resolved automatically by the agent from your identity provider.
Dual approval is configured per tool. For example, you might require only technician approval for adding a user to a standard app group, but require both technician and manager approval for resetting an admin account password.
## Script analysis on approval plans
When the agent proposes a plan that includes a script it wrote itself, Rallied analyses the script and shows a plain-English summary in every approval channel. The analysis is advisory only: you still review and approve the plan yourself.
The script analysis appears in:
* PSA ticket notes (ConnectWise notes render cleanly)
* Slack approval messages
* Teams approval messages, where applicable
* The admin chat approval card
Each analysis includes:
* What the script reads (local system information, registry, Active Directory, network hosts)
* What it changes (services, processes, files, registry, configuration, and so on)
* Security-sensitive items that always need human review (credential access, account changes, persistence, security control changes, network exfiltration, encoded code, child shells, installers)
* Parts that could not be analysed (unknown commands, non-literal paths, syntax the parser did not recognise)
* Where and as whom the script runs (target device count and run-as account)
* An advisory line on whether the script matches what the plan says it does
The analysis cannot decide for you. It gives you the facts so your approval is informed. If the analysis says "Script analysis unavailable," review the script yourself before approving.
Analysed scripts include PowerShell and Bash written by the agent for ConnectWise RMM generic runner templates, NinjaOne Bash runners, and library task runners on a generic runner template (like ConnectWise RMM run task). Bash analysis also handles common read-only utilities such as `crontab -l`, `find`, and text-processing tools.
CMD scripts and scripts larger than 16 KB are not analysed. Scripts that do not parse, or scripts in an unrecognised runner language, show a fallback message instead.
## How approval requests expire
Approval requests expire automatically **14 days** after the agent proposes the plan if no one approves or denies them. This window is fixed and not configurable. After a request expires, none of the plan's steps can run.
If someone approves or denies after the deadline, Rallied does not apply the decision. Instead, Rallied replies on the channel they used (a PSA internal note, a Slack reply, or the approval link page) to say the request expired and nothing was carried out. If the work is still needed, ask the agent to propose the plan again.
Once you approve a plan, the agent has a full 14 days from the approval to carry it out. A plan approved on day 13 is not cut off on day 14.
An approved request can only be used once and is tied to the specific plan the agent submitted. If you approve a request, the agent executes exactly the plan that was presented, nothing more.
## Approvals cancelled when a ticket closes
When a ticket is closed or resolved, any still-pending approval requests for that ticket are automatically cancelled. A late reply on a closed ticket cannot wake the agent to execute a plan written for a conversation that has already ended.
This applies to every approval channel: PSA notes, Slack, Teams, and the admin chat card. A cancelled approval is treated the same as an expired one: the agent informs the requester that the approval was not completed in time.
## Approval settings
You configure per-action approval on each integration's detail page (open it from the client's or MSP's **Integrations** tab):
| Setting | What the agent does |
| - | - |
| **Auto-approve** | Runs immediately, no approval needed. |
| **Needs approval** | Pauses and asks a technician to sign off before running. Optionally also requires manager approval. |
| **Disabled** | The action is off for this client. |
## How to set Execute Mode for a client
![The Operating Mode section with Plan and Execute options]()
1. Open the client's detail page in Rallied.
2. On the **Overview** tab, find the **Operating Mode** section.
3. Click **Execute Mode**.
To make Execute Mode the default for all clients, open your MSP's detail page and click **Execute** in the **Operating Mode** section on the **Overview** tab. Any client set to **Inherit** will follow this default.
Before switching a client from Plan Mode to Execute Mode, review the internal notes the agent posted during Plan Mode to confirm its judgment matches your expectations. See [Plan Mode](/agents/plan-mode) for guidance on the evaluation process.
## Related
* [Plan Mode](/agents/plan-mode) — the read-only mode to start every client in.
* [Approval settings](/dashboard/policies) — decide which actions run on their own.
* [Memory](/dashboard/memory) — review the corrections the agent learns from Execute Mode tickets.
* [Performance](/dashboard/performance) — track outcome and zero-touch rates once a client is live.
# Identity Verification
Source: https://docs.rallied.ai/agents/identity-verification
Stop social-engineered password resets: require an MFA push through Duo, Traceless, or Microsoft Authenticator before the agent runs sensitive actions.
For sensitive operations like password resets, admin account creation, and permission changes, the agent can require the requesting employee to verify their identity with multi-factor authentication before executing. This confirms the person asking for a sensitive action is actually who they say they are, not just anyone who got their hands on the originating ticket, call, or chat.
## How it works
When the agent determines that a requested operation is sensitive, it pauses execution and initiates an identity verification challenge with the employee's MFA provider. The employee must approve a push notification on their authenticator app before the agent proceeds.
As the agent builds its plan, it identifies that one or more steps require elevated assurance, such as resetting a Microsoft 365 password or creating a new admin account.
The agent calls the identity verification service, which sends a push notification to the employee's authenticator app (Microsoft Authenticator or Duo Mobile, depending on your configuration). The agent tells the employee on the source ticket, call, or chat that they will receive a verification push and should approve it.
The employee opens their authenticator app and approves the push notification. This confirms their identity.
Rallied monitors the verification result automatically, either by polling the provider or receiving a webhook callback. The agent does not need to ask the employee anything further.
If the employee approved the push:
* The agent proceeds with the sensitive operation and confirms completion on the source ticket, call, or chat.
If the employee denied the push or the verification timed out:
* The agent reports the failure on the source ticket, call, or chat and does not execute the action. The employee can resubmit their request if they want to try again.
## Supported providers
When your Microsoft 365 integration is connected, the agent triggers MFA through the user's registered method, typically a push to **Microsoft Authenticator**, and falls through to whatever the user has configured.
* The employee receives a standard Microsoft Authenticator push, identical to the ones they already use for Microsoft 365 sign-ins.
* The result is resolved automatically through Microsoft Graph. No action is required from your technicians.
When your Duo integration is connected, the agent sends a push notification through the **Duo Mobile** app on the employee's enrolled device.
* The employee receives a standard Duo push notification.
* Duo notifies the backend of the result via webhook when the employee responds.
* No action is required from your technicians; the verification result is resolved automatically.
When your [Traceless](/integrations/traceless) integration is connected, the agent sends a verification request to Traceless, which routes the push to the employee's existing authenticator (Microsoft Authenticator or Duo Mobile) based on the **Default Push Method** you selected when connecting.
* Traceless finds the right device for that employee against your connected MFA system.
* The backend polls Traceless every few seconds for up to 5 minutes until the verification resolves.
* Use Traceless when your end users have mixed MFA tools and you want a single connection that covers all of them.
## Configuration
Identity verification does not require any configuration beyond connecting your MFA integration. Once Microsoft 365, Duo, or Traceless is connected, the agent automatically triggers identity verification whenever it determines an operation is sensitive.
Credential resets, admin privilege changes, and permission grants always trigger identity verification. The agent classifies the request automatically; you don't define which operations qualify.
If you use Traceless, you can turn off requester verification from its integration detail page. When it's off, Traceless sends no push. A technician must approve the agent's plan instead, and the plan states that the requester's identity was not verified. See [Turn off requester verification](/integrations/traceless#turn-off-requester-verification).
## What happens when verification fails
The agent immediately stops. It reports the denial on the source ticket, call, or chat and does not execute the action. The employee can resubmit their original request if they want to try again.
If the employee does not respond to the push notification within the provider's timeout window (up to 3 minutes for Microsoft 365; up to 5 minutes for Traceless; Duo uses its own configured timeout), the verification expires. The agent reports the timeout on the source ticket, call, or chat and does not execute the action.
If the employee has no MFA device enrolled with the connected provider, the push cannot be delivered. The agent reports that verification could not be completed and escalates the request to your technicians for manual handling.
If verification fails or times out, the agent never executes the sensitive operation, regardless of other approvals already in place. A fresh verification is required for each new attempt.
# Plan Mode
Source: https://docs.rallied.ai/agents/plan-mode
Onboard new clients with confidence: the agent diagnoses live tickets and posts what it would do as a private note, without touching your systems.
Plan Mode lets you watch your agent think without letting it act. The agent reads incoming requests, diagnoses them using only read-only tools, and writes up what it would have done, but stops there. No tickets are updated, no accounts are touched, no employees are notified.
Use Plan Mode when you're onboarding a new client, auditing the agent's judgment, or simply want to build confidence before going live.
## What the agent does in Plan Mode
When a request arrives (a new ticket in your PSA, or a message in Slack or Teams where you've connected one), the agent:
1. **Diagnoses silently** — it uses read-only tools (looking up users, checking account status, reviewing group memberships, reading your runbooks, etc.) to understand the request fully.
2. **Posts a single internal note** — it writes up its diagnosis and the plan it **would have** executed if it were in Execute Mode. The note goes on the source ticket: a note on the ConnectWise ticket, an action in HaloPSA, a comment on the Autotask ticket, and so on. Your team can see it; the employee cannot.
3. **Stops completely** — no tool executions, no approval requests sent to your technicians, no reply to the employee.
The employee who submitted the request receives no response in Plan Mode. If you are running Plan Mode on an active client, make sure your team is handling requests through your normal workflow in the meantime.
## What Plan Mode does NOT do
The agent never writes, creates, modifies, or deletes anything. It only reads.
Your technicians will not receive approval notifications in Plan Mode.
The agent doesn't answer the employee's ticket or chat. Your team handles it through your normal workflow.
The agent does not escalate, route, or forward requests to anyone.
## When to use Plan Mode
When you first connect Rallied to a client's environment, Plan Mode lets you verify that the agent correctly understands the client's stack (their identity provider, ticketing system, app catalog, and user directory) before any real action runs.
Review the internal notes the agent posts over days or weeks. Check whether its diagnoses match what your technicians would have done. If the plans look right, you're ready to move forward.
Use Plan Mode as a final gate before enabling live execution. It gives you a documented record of how the agent reasons about your client's specific request types.
You can switch an active client back to Plan Mode at any time if you want to audit the agent's behavior after a change in their environment or policies.
## How to enable Plan Mode
You can set the agent mode at two levels: for your entire MSP (the default that all clients inherit) or for an individual client.
![The Operating Mode section with Plan and Execute options]()
**Setting the MSP default:**
1. Open your MSP's detail page from the sidebar.
2. On the **Overview** tab, find the **Operating Mode** section.
3. Click **Plan**. All clients set to **Inherit** will now operate in Plan Mode.
**Setting mode for an individual client:**
1. Open the client's detail page.
2. On the **Overview** tab, find the **Operating Mode** section.
3. Click **Plan Mode**. The change takes effect on the next request the agent handles.
## Mode hierarchy
Every client either inherits your MSP-level default or overrides it individually. When a client is set to **Inherit**, they follow whatever mode you have configured at the MSP level.
```text theme={"system"}
MSP default: Plan Mode
├── Client A — Inherit → Plan Mode
├── Client B — Inherit → Plan Mode
└── Client C — Execute Mode (overridden individually)
```
This means you can run Plan Mode by default for all new clients while individually promoting mature clients to Execute Mode as they become ready.
## Transitioning to Execute Mode
When you're satisfied with the agent's judgment for a client, promote them to Execute Mode:
Look at the notes the agent has posted on tickets over the evaluation period. Confirm the diagnoses and proposed plans are accurate for this client's environment.
Open each connected integration from the client's **Integrations** tab and confirm each action is set the way you want: **Auto-approve** for safe read-and-write operations you're comfortable automating, **Needs approval** for anything you want a technician to review first.
On the client's **Overview** tab, click **Execute Mode** in the **Operating Mode** section.
Open a low-risk test ticket against the client in your PSA. Verify the agent picks it up, responds correctly, and routes any approvals to your technicians as expected.
Start with your most straightforward clients, the ones with a single identity provider and a small, well-defined app catalog. Plan Mode reviews go faster when the environment is simple.
## Related
* [Execute Mode](/agents/execute-mode) — switch a client once you trust the plans.
* [Performance](/dashboard/performance) — why outcome rates stay at zero while a client is in Plan Mode.
* [Memory](/dashboard/memory) — memories are only learned from Execute Mode clients.
* [Clients](/dashboard/clients) — set the mode per client.
# Rallied API
Source: https://docs.rallied.ai/api
Put your Rallied agent to work from your own scripts and automations: send it a prompt about any PSA ticket and act on the reply programmatically.
The Rallied API lets you talk to your agent about any PSA ticket from your own scripts, automations, and internal tools. Create a bearer token, `POST` a prompt with the ticket's integration slug and ID, and the agent replies with the same reasoning it uses in chat, respecting the client's Plan Mode and approval policies.
To use the API, you must be an MSP admin with a PSA connected under **Settings → Integrations**.
## Create an API token
Go to **Settings → API Tokens**.
Enter a name that identifies what will use it (for example, `PSA automation`), then click **Create token**.
The full token is shown once. Copy it into your secrets manager, then click **Done, I saved it**.
If you close the panel before copying, click **Revoke** next to the token, confirm, and create a new one.
![The API Tokens page showing a newly created token with the Done, I saved it button]()
The token is displayed once. Rallied stores only a hash, so it cannot be shown to you again. If you lose it, revoke it and create a new one.
Tokens do not expire. Each token displays a **last used** time. Use it to spot tokens that are idle or, conversely, tokens that are still active when they shouldn't be.
Store tokens in a secrets manager or environment variable, never in source control or chat. Issue one token per calling system so you can revoke any single token without disrupting the others. Revoke immediately if a token is leaked.
## Revoke a token
On **Settings → API Tokens**, click **Revoke** next to the token, then click **Confirm revoke**.
Subsequent calls with that token fail immediately with a 401. Revoked tokens remain in the **Revoked** list so you have a record of when each one was retired.
![The API Tokens page after revoking, with the token listed under Revoked]()
## Talk to your agent about a ticket
```text theme={"system"}
POST https://api.rallied.ai/api/v1/talk
Authorization: Bearer rall_pat_
Content-Type: application/json
```
A single token can act on any client and any ticket in your MSP.
### Request body
Slug of the connected PSA that holds the ticket. Lowercase letters, digits, `_`, and `-`. Maximum 64 characters. See [Integration slugs](#integration-slugs).
The ticket number or ID in that PSA. Letters, digits, `.`, `_`, and `-`. Maximum 64 characters. The ticket must already exist in Rallied (see [How the conversation works](#how-the-conversation-works)).
What you want to ask or tell the agent. 1 to 20,000 characters.
### Integration slugs
| PSA | `integration` value |
| - | - |
| ConnectWise Manage | `connectwise_psa` |
| HaloPSA | `halo_service_solutions` |
| Autotask | `autotask` |
| SuperOps | `superops` |
You can also copy the slug from the **API slug** chip on the integration detail page under **Settings → Integrations**.
### Example request
```bash theme={"system"}
curl -X POST https://api.rallied.ai/api/v1/talk \
-H "Authorization: Bearer $RALLIED_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"integration": "connectwise_psa",
"ticketId": "48213",
"prompt": "Summarize what has happened on this ticket and what you would do next."
}'
```
### Example response
```json theme={"system"}
{
"reply": "The user reported they cannot open shared mailboxes since Monday. ...",
"thinking": "Optional. Present only when the agent shares its reasoning.",
"turnId": "3f9c2a6e-1b6d-4d1a-9f0e-2a7c8d1e5b44",
"sessionKey": "agent:contoso:connectwise_psa:48213:api",
"clientSlug": "contoso",
"mode": "execute",
"elapsedMs": 8421
}
```
The agent's answer to your prompt.
The agent's reasoning, when it shares it. Omitted when empty.
Unique ID for this request/response exchange.
Identifier for the conversation this exchange belongs to. Stable for a given integration and ticket, so follow-up calls continue the same conversation.
Slug of the client that owns the ticket.
`plan` when the client is in Plan Mode, `execute` when the client is in Execute Mode.
How long the agent took to answer, in milliseconds.
## How the conversation works
**Rallied must already know the ticket.** The API does not look tickets up in your PSA. It only sees tickets that arrived by webhook while the integration was enabled, for companies that are active clients. You'll get a 404 if the ticket predates the integration, the company isn't an active client, or the client is paused.
**Each ticket has its own API conversation.** Repeat calls for the same integration and ticket continue that conversation, so you can ask follow-up questions. This conversation is separate from the work the agent does on the ticket itself: your prompts don't change how the agent handles the ticket.
**The agent answers you, not the ticket.** It won't post to the ticket unless your prompt explicitly tells it to.
**Plan Mode and approval settings still apply.** In Plan Mode the agent only reads and plans. In Execute Mode, actions marked **Needs approval** wait for a technician, exactly as they do in [chat](/dashboard/chat).
**Calls block until the agent replies.** If the agent takes too long, you'll receive a 504 with the same `turnId` and `sessionKey`. The agent keeps working. Retry the same call to continue the conversation.
**Every exchange is logged in Activity** as an API chat on the ticket, so your team can see what you asked and how the agent responded.
## Errors and limits
Every error response is JSON with a single `error` string.
| Status | `error` | What to do |
| - | - | - |
| 401 | `invalid or revoked token` | Check the `Authorization` header and the token. Rallied returns this same message for missing, malformed, unknown, and revoked tokens. |
| 404 | `integration not found` or `ticket not found` | The slug isn't a connected, enabled integration in your MSP, or Rallied has no record of the ticket. Rallied does not query the PSA to verify. |
| 405 | `Method not allowed` | Use `POST`. |
| 422 | `integration (slug [a-z0-9_-], max 64), ticketId ([A-Za-z0-9._-], max 64) and prompt (1-20000 chars) are required` | Fix the request body. The field is `integration`, not `integrationId`. |
| 429 | `Too many requests, slow down` | Back off until the time in the `Retry-After` header. |
| 502 | `agent did not accept the message` or `agent turn failed; please retry` | Wait briefly, then retry. |
| 503 | `agent runtime unavailable` | The agent for your MSP is starting or temporarily unavailable. Retry in about a minute. |
| 504 | `agent did not reply within the timeout; the turn may still complete` | The agent is still working. Send the same request again to continue. |
Rate limits are applied in two tiers:
* 600 requests per minute per IP address
* 30 requests per minute per token
Every response includes `RateLimit-Limit`, `RateLimit-Remaining`, and `RateLimit-Reset`. A 429 additionally includes `Retry-After`.
Some networks close idle requests after about 100 seconds, which can happen before Rallied's own timeout. Treat a dropped connection as a 504: the agent keeps working, and the next call for the same ticket continues the conversation.
## Related
* [Chat with your agent](/dashboard/chat) — the same conversation, from inside Rallied or ConnectWise.
* [Approval settings](/dashboard/policies) — control which actions the agent can run from an API conversation.
* [Plan Mode](/agents/plan-mode) — what the agent does when `mode` is `plan`.
* [Integrations](/dashboard/integrations) — connect the PSA whose slug you pass as `integration`.
* [Credits & Billing](/billing/credits): API prompts about a ticket are billed in credits as part of that ticket.
# How Rallied credits work: pricing, plans and top-ups
Source: https://docs.rallied.ai/billing/credits
Rallied bills each ticket the agent works at 1, 3 or 8 credits. Learn what each level costs, what's free, the plan and trial, credit packs and auto top-up.
Rallied bills the work its agent does in credits. Each ticket the agent works costs 1, 3 or 8 credits, charged once, depending on how much the agent had to do on it. A credit is worth \$0.10, the plan includes 2,000 credits a month, and you buy more only when you choose to.
A ticket costs the same whether it closes or not. You pay for work the agent did, never for work it tried and could not do, and you are never charged twice for the same ticket.
## The plan and the trial
The Rallied plan is **\$150 a month with 2,000 credits included**. Every integration and every surface is on, and there is no limit on how many clients the agent covers. There is one plan, with no tiers, billed monthly.
* **Rollover:** unused included credits roll over for one month and are used first. A slow month's credits carry into the next one and lapse at the end of it.
* **Trial:** a new account starts on a 14-day trial of the same plan with the same 2,000 credits, no card required. The trial starts when you first connect your PSA.
* **Converting:** add a card on the **Billing** page at any time. Your paid month starts with a fresh 2,000 credits the moment you add it. Unused trial credits expire on conversion and don't carry into the paid month.
* **Trial ends without a card:** the agent pauses and your data stays put. A trial can't buy credit packs, because there is no card to charge.
* **Failed plan charge:** the **Billing** page says so and the agent pauses until the card is fixed.
## What one ticket costs
A ticket is charged once, at the highest level the agent reached on it. The agent may come back to a ticket several times (after a technician note, an approval, or a status change). None of that adds a charge unless it lifts the ticket to a higher level.
| Level | Credits | What the agent did | Examples |
| - | - | - | - |
| **Simple** | 1 | Handled the ticket itself. Replies to the requester and PSA status or priority lookups count here. | Summarizes the request in an internal note. Replies to the requester, or asks for a missing detail. |
| **Standard** | 3 | Worked in one or more of your systems, reading or changing things. | Pulls the device from NinjaOne and notes the likely cause. Checks the user in Microsoft 365 and resets their password. |
| **Complex** | 8 | Worked across three or more of your systems with six or more different tools, or ran a script. | Checks the device in NinjaOne, sign-ins in Microsoft 365 and the runbook in IT Glue, then unlocks the account in Okta. Runs an RMM script against the endpoint. |
Three rules decide the level:
* **The ticket's own record never counts as a system.** Reading or noting the ticket in your PSA is not a system. Only your other integrations count.
* **Reads and changes count the same.** Each different tool is one tool. Calling the same tool again counts once, so retries never raise a ticket. Systems and tools from every turn on the same ticket add up.
* **A ticket never moves down.** It is graded at its highest level. If it reaches a higher level later, you are charged only the difference (2, 5 or 7 credits).
### Plan Mode, Execute Mode and approvals
In [Execute Mode](/agents/execute-mode), a ticket that needs approval is one ticket, not two. The agent proposes a plan (Standard so far, 3 credits), a technician approves, and the agent runs it. If the plan and the fix together reach three systems and six tools, the ticket becomes Complex: 8 credits in total, 3 when the plan was posted and 5 more when the fix ran. Otherwise it stays at 3.
[Plan Mode](/agents/plan-mode) tickets are billed the same way, because the diagnosis is the work. A deep investigation in Plan Mode can be Complex.
### Chat, Teams, Slack and the API
Messages in the [admin chat](/dashboard/chat), [Microsoft Teams](/integrations/microsoft-teams) intake and Slack are charged per message, at the same three levels. A chat message the agent answers without touching any system is Simple. Prompts sent through the [API](/api) about a specific ticket are billed as part of that ticket.
## What never costs credits
* A ticket the agent failed on or did not finish, with nothing else done. If some calls to your systems succeeded before the error, the ticket is graded on those alone.
* A ticket where every tool call was refused by a [policy](/dashboard/policies), or where the agent only learned an approval was denied.
* A ticket on which the agent made no tool call at all, such as a clarifying question.
* Tickets filtered out as noise, which never wake the agent.
* Tickets for clients the agent doesn't cover.
* Heartbeats, syncs, ticket mirroring and classification.
* Notes Rallied posts itself, such as the [identity verification](/agents/identity-verification) outcome or the paused notice.
* Asking the admin chat about your balance.
* Connecting integrations, editing workflows, changing policies, and everything else you do to set the agent up.
## Worked examples
The agent reads the ticket, checks Okta and Microsoft 365, and posts an internal note recommending an unlock. That's Standard, 3 credits. The technician approves, and the agent unlocks the account in Okta and posts the result. Two systems is still Standard, so the ticket stays at 3 credits (\$0.30), however many times the agent came back to it. Had it also checked sign-ins and the IT Glue runbook (three systems, six tools), it would have been Complex, 8 credits.
The agent reads the ticket and the device record in NinjaOne, sees the printer hasn't checked in since Friday, and notes that it needs a site visit. That's one Standard ticket, 3 credits. The technician adds a note the next day and the agent answers from the ticket alone. Still 3 credits.
A typical mix of tickets averages about 4 credits each, so the plan's 2,000 credits cover roughly 500 tickets a month.
## Buying more credits
When the included credits run low, buy more in packs from the **Usage** page (**Settings → Usage → Buy credits**).
| Pack | Price |
| - | - |
| 500 credits | \$50 |
| 1,000 credits | \$100 |
| 2,500 credits | \$250 |
Packs are the same \$0.10 per credit as the plan. The card on file is charged right away, and the credits land only after the payment goes through. Purchased credits **never expire**.
Each pack is its own card charge with its own invoice. New accounts can buy 2 packs a day until two invoices have been paid (automatic packs count toward this).
### Which credits are used first
1. Last month's rolled-over included credits.
2. This month's 2,000 included credits.
3. Coupon credits.
4. Purchased packs, oldest first.
Because purchased credits are used last and never expire, buying early never wastes them.
### Auto top-up
Auto top-up is **off** until an admin switches it on from the **Billing** page. It needs a card on file and the paid plan, so it isn't available during the trial.
While it's on, whenever your balance drops below 100 credits, Rallied buys a 500-credit pack (\$50) on the card on file, exactly as if you had clicked **Buy credits**. Credits the agent is about to spend on work already under way count as spent, so a busy moment tops up before the agent would pause.
* **Monthly limit:** when you switch it on, pick a limit of $100, $250, $500 or $1,000 (2, 5, 10 or 20 packs per billing period). \$250 is preselected; change it later with **Edit limit**. The **Billing** page shows what's been spent this period.
* **At the limit:** nothing more is bought until the next period, the agent pauses at 0 credits as usual, and every admin gets one email. You can still buy a pack by hand.
* **Notifications:** every automatic pack is emailed to every admin and appears on the Activity page and invoices, marked as automatic.
* **Failed charge:** if a charge fails or the bank asks for cardholder confirmation, nothing is added, auto top-up switches itself off, and every admin is emailed. Update the card, then switch it back on.
### Coupons
Rallied sometimes issues coupon codes worth free credits. An admin enters the code on the **Billing** page under **Have a coupon?** and the credits are added at once. Each code works once per account, during the trial or after it. Coupon credits never expire, and coupon credits redeemed during the trial carry over when you add a card.
## Usage alerts
Every admin gets an email, and a banner on the **Usage** page, at four points. These are always on. They count only this month's 2,000 included credits, so "half way" always means 1,000 left.
| Alert | When |
| - | - |
| Half way | 1,000 of the 2,000 included credits used |
| 80% | 1,600 of the 2,000 included credits used |
| Included used | All 2,000 included credits used. The agent keeps working on purchased credits and pauses when those run out. |
| Paused | The agent has stopped taking new work, with the reason and a **Buy credits** button |
## When credits run out
The agent stops taking new work once your remaining credits can no longer cover the tickets it is already working. Nothing else changes:
* Tickets keep arriving, being mirrored into Rallied and being classified.
* On ConnectWise and HaloPSA, each ticket the agent would have worked gets one internal note saying the agent is paused, so your technicians know to pick it up.
* The Activity page lists every ticket the agent skipped.
* Work already under way finishes. Any credits it spends past zero are absorbed by Rallied and never invoiced.
The agent resumes by itself as soon as a pack is granted (bought by hand or by auto top-up), a coupon is redeemed, or the month rolls over. Skipped tickets aren't replayed; a skipped ticket is worked when the next event on it arrives. A plan a technician approved while the agent was paused runs when the agent resumes, as long as the ticket is still open and the approval is less than a week old.
## Where to see your balance and spend
**Settings → Usage** shows credits remaining, included credits used and when they refresh, purchased credits held, a month-end projection, and a daily chart. **Buy credits** lives here.
**Settings → Billing** holds your plan, card, auto top-up switch, coupons and invoices.
A **Credits** column and level badge on each ticket the agent worked, with free tickets showing the reason. Sort by credits to find the most expensive tickets.
The monthly usage invoice lists the tickets the agent worked by level (Simple, Standard and Complex), each with a count, plus a **Level upgrade** line for credits added when a ticket rose to a higher level after it was first billed.
## FAQ
No. One ticket, one charge, at the highest level reached. The Activity page shows one row for it.
No. The ticket is charged once, at the level it ends up at. If the approved fix lifts it from Standard to Complex, only the difference (5 credits) is added.
Any integration other than the ticket's own record, such as your RMM, identity provider, Microsoft 365, a documentation tool or web search. Reading or noting the ticket itself never counts.
No. A ticket is at most 8 credits, however many times the agent comes back to it. Nothing is bought unless you buy it or switch on auto top-up with a monthly limit.
Included credits roll over for one month. Purchased and coupon credits never expire.
Nothing is added and nothing else changes. The Usage page tells you, you get an email, and you can update the card on the Billing page and try again.
Questions about your bill? Email [support@rallied.ai](mailto:support@rallied.ai).
# Activity
Source: https://docs.rallied.ai/dashboard/activity
Know exactly what the agent did, when, and why: a full audit trail of sessions, tool calls, and approval decisions for every ticket, ready for compliance.
The **Activity** tab on each client's detail page is your full audit trail for the agent. Every tool call, approval decision, and conversation is logged automatically, so you can retrace exactly what the agent did on a ticket, when it did it, and which technician (if any) signed off. Use it to spot-check the agent's work, investigate a specific incident, or gather evidence for a compliance review.
## Activity log
The **Activity** tab shows a chronological list of all tool executions for a client. Each entry includes:
* **Timestamp** — when the action occurred
* **Tool name** — which integration tool was called (e.g., `m365-reset-password`, `connectwise-add-ticket-note`)
* **Parameters** — the inputs passed to the tool
* **Result** — whether it succeeded or failed, with a summary of the output
* **Triggered by** — the session that initiated the call
Use the activity log to:
* Audit what the agent did in response to a specific employee request
* Verify that approvals were properly enforced
* Investigate unexpected behavior
![The Activity log listing agent sessions with their tool call counts]()
Conversation transcripts are surfaced inline in the **Activity** log. There is no separate **Sessions** tab. Open an activity entry to see the agent's reasoning, the messages exchanged, and any approval requests that were raised alongside the tool calls.
![An expanded activity entry showing the agent's tool calls]()
There is also an MSP-wide **Activity** view under **Settings → Activity** that aggregates activity across every client under your MSP, useful when you need to see what's happening platform-wide rather than per client.
![The MSP-wide Activity view under Settings listing recent agent sessions across clients]()
## Credits
The **Activity** page also shows what the agent's work cost. Each ticket the agent worked is one row with a **Credits** column and a level badge (Simple, Standard or Complex), however many times the agent came back to it. A ticket that cost nothing shows zero with the reason it was free, and a ticket still being graded shows **pending**. Credit packs, including automatic top-ups, and redeemed coupons appear as their own rows. Sort by **Credits** to find the tickets that cost the most. See [Credits & Billing](/billing/credits) for how levels are decided.
## Diagnostics
The **Diagnostics** tab shows the operational health of the agent running for this client. It includes:
* **Agent status** — whether the agent is running, stopped, or in an error state
* **Recent logs** — the agent's output, useful for identifying errors
* **Disk and memory usage** — resource consumption on the agent's server
If a client's agent is unresponsive, check the **Diagnostics** tab first. Status and recent errors are visible here without needing to contact support.
## Related
* [Performance](/dashboard/performance) — the rates computed from this log.
* [Memory](/dashboard/memory) — see the tickets a memory was learned from.
* [Execute Mode](/agents/execute-mode) — what an approval looks like in the log.
* [Restricting access with IP allowlists](/dashboard/security) — lock down who can read the log.
# Chat with your agent
Source: https://docs.rallied.ai/dashboard/chat
Get answers, kick off actions, and work tickets side-by-side with your agent from the Rallied dashboard or right inside ConnectWise Manage.
Chat is a direct line to your agent for the times you want to drive the work yourself. Open the **Chat** tab, describe what you want, and the agent works alongside you: it pulls ticket context, drafts replies, runs tools, and pauses for approval whenever a policy requires it. It's the fastest way to hand the agent a task without waiting for a ticket to trigger it.
You can chat with your agent from two places:
* **In Rallied** — a **Chat** tab available on every MSP workspace.
* **Inside ConnectWise Manage** — the same chat, embedded as a pod so your technicians never leave the PSA.
Everything you say, every plan the agent posts back, and every approval you give is scoped to your MSP; a chat opened by one technician cannot see another MSP's tickets or clients.
## Chatting from Rallied
Open your MSP in Rallied and switch to the **Chat** tab. You'll see a threaded chat with a sidebar of past conversations on the left.
![The Chat tab with a new conversation ready to start]()
What you can do here:
* **Ask about a ticket** — paste a ticket number or subject and the agent pulls the ticket, its notes, and the customer context.
* **Kick off an action** — "reset Jane's password", "grant Alex access to the finance shared mailbox", "check whether server-03 is up". The agent picks the right tool and posts a plan for your approval when needed.
* **Work an incident together** — walk through diagnosis step by step, with the agent surfacing findings as it goes.
* **Ask questions about your setup** — "which clients don't have MFA enforced?", "what workflows do we have for onboarding?"
* **Build reports and make bulk changes across clients** — "export every RMM device that hasn't checked in for 30 days as a CSV". The agent runs a sandboxed script and shares the files as download cards in the chat. See [Scripts and reports](/dashboard/chat-scripts).
Each conversation is a **thread**. Threads are per-technician: your colleagues don't see yours and you don't see theirs. Rename or delete a thread from the sidebar.
The agent respects the same approval settings you've configured for the rest of Rallied. If a tool is set to **Needs approval**, the agent posts its plan and waits for you to reply "yes"/"go ahead"/"no, do X instead" before running it. See [Approval settings](/dashboard/policies).
When a plan includes a script the agent wrote itself, the approval card shows a **Script analysis** block under the step. This is a plain-English summary of what the script reads, what it changes, any security-sensitive items, and whether it matches what the plan says. The analysis is advisory: you still decide whether to approve. See [Script analysis on approval plans](/agents/execute-mode#script-analysis-on-approval-plans) for details.
## Chatting from inside ConnectWise Manage
If you use ConnectWise Manage, you can embed the same chat inside the PSA using ConnectWise's **Hosted API**, with no extra window and no context-switching. Your technician opens a ticket, opens the Rallied pod, and asks the agent to help.
### One-time setup in ConnectWise
In ConnectWise Manage, go to **System → Setup Tables** and open **Hosted API**.
Click **New**. Fill in:
* **Description** — `Rallied`.
* **Screen** — pick the screens you want the pod to appear on (Service Ticket is the most useful).
* **URL** — `https://app.rallied.ai/embed/connectwise`.
* **Origin** — `https://app.rallied.ai`.
Save the entry, then reload ConnectWise Manage. The Rallied pod now shows up in the sidebar of every screen you enabled it on.
### What your technicians see
When a technician opens the pod on a ticket, ConnectWise hands Rallied the ticket ID and the login of the current CW user. From there:
* **Ticket context loads automatically**, with no pasting IDs and no searching. The agent knows which ticket you're on.
* **The chat is scoped to your MSP.** Rallied checks that the ConnectWise instance the pod was loaded from actually belongs to your MSP. If someone pasted the pod URL into a different tenant, the pod blocks the chat instead of leaking anything cross-tenant.
* **Approvals happen inline.** Same plan-and-approve flow as the rest of Rallied.
### When the pod can't open
You may see one of these instead of a chat:
| What you see | What it means | What to do |
| - | - | - |
| **ConnectWise isn't connected** | Your MSP hasn't set up the ConnectWise integration in Rallied. | Connect ConnectWise in **Settings → Integrations**. See [ConnectWise Manage](/integrations/connectwise). |
| **This ConnectWise instance doesn't match** | The pod was opened from a different ConnectWise tenant than the one connected to your MSP. | Check that the ConnectWise instance the pod is embedded in is the same one you connected. If you have more than one CW tenant, connect the correct one. |
| **Choose an MSP** **(platform admins only)** | You're a Rallied platform admin and the pod couldn't tell which MSP to load. | Pick the MSP from the list. Regular technicians never see this. |
## Common patterns
* **Working from a ticket** — open the ConnectWise pod, say **"help me work this"**, let the agent pull the customer's setup and suggest next steps.
* **Bulk asks** — from the Chat tab, **"list every ticket about printer issues in the last 48 hours"** or **"who's overdue on onboarding tasks?"**. The agent pages through long lists instead of stopping at the first page of results.
* **Running a workflow ad-hoc** — describe the outcome you want ("**offboard Jamie in Contoso**") and let the agent walk through the same steps a matching workflow would run automatically.
## Credits
Each chat message is charged once, at the level of work the agent did for it: Simple (1 credit) when it answers without touching any of your systems, Standard (3) when it works in one or more systems, and Complex (8) when it works across three or more systems with six or more tools, or runs a script. Messages where every call was refused or the agent didn't finish are free, and so is asking **"how many credits do we have left?"**. See [Credits & Billing](/billing/credits).
## Related
* [Credits & Billing](/billing/credits): how chat messages are charged.
* [Scripts and reports](/dashboard/chat-scripts) — run a script across every client and approve bulk changes once.
* [Approval settings](/dashboard/policies) — decide which actions the agent runs on its own vs. asks about.
* [Workflows](/dashboard/workflows) — write playbooks that run automatically when matching tickets come in.
* [ConnectWise Manage](/integrations/connectwise) — connect the PSA the pod embeds into.
* [Rallied API](/api/talk) — the same ticket conversation from your own scripts and tools.
# Run scripts and reports across clients from Chat
Source: https://docs.rallied.ai/dashboard/chat-scripts
Have your agent run a sandboxed script across every client to build CSV reports, then approve one dry-run-checked program to make bulk changes.
Some requests are too big for one tool call. "Which devices across all our clients haven't checked in for 30 days?" means the same lookup for every client, then grouping and counting the results. For these requests, the agent in [Chat](/dashboard/chat) writes a short Python program and runs it in a sandbox. The program calls the agent's read tools for you, combines the results, and saves CSV files you can download.
Scripts are on by default for every MSP. You don't need to configure anything.
## When the agent uses a script
The agent writes a script when your request needs:
* **The same lookup across many clients**, such as "list every open ticket older than 14 days, per client".
* **Counting, grouping, or joining results**, such as "how many Microsoft 365 licenses does each client pay for in Pax8 compared to what's assigned?".
* **A CSV report**, such as "export every ConnectWise RMM device with its last check-in time".
For a single lookup, the agent calls the tool directly instead.
Ask in plain language. You don't write the program yourself:
```text theme={"system"}
Build a CSV of every ConnectWise RMM device that hasn't checked in for 30 days,
grouped by client. Try two clients first, then run it for all of them.
```
When a report covers "all clients", the agent fetches data client by client. It only includes vendor companies that are linked to a Rallied client. The agent then tells you how many vendor companies it left out because they aren't linked.
## What a script can read
A script can only run a short, reviewed list of read tools:
* **ConnectWise PSA** — ticket lookups and most list reads. Configuration lists are excluded because they can hold passwords.
* **ConnectWise RMM** — list reads and script task results.
* **Pax8** — list and detail reads.
* **Microsoft 365** — Microsoft Graph list reads.
Every call a script makes goes through the same tenant checks and [approval settings](/dashboard/policies) as the agent's own calls. A tool set to **Disabled** stays off, and scripts only run read tools set to **Auto-approve**.
Scripts share each vendor's API rate limit with your agents. Your agents always keep part of that limit in reserve, so a long report never slows down ticket work.
## Dry runs: nothing changes until you approve
By default, every script runs as a **dry run**. If the program tries a write, such as adding a ticket note or starting an RMM script, Rallied records the change instead of making it. The agent then lists what would have changed and says plainly that nothing was changed.
Scripts can never reset or send credentials. Rallied refuses those calls outright, even in a dry run.
## Approving a script for bulk changes
After a dry run that recorded changes, the agent asks for **one approval for the whole program**. This covers every client it touches, instead of one approval per change.
Describe the bulk change, for example "add an internal note to every open ticket from Contoso that's waiting on the customer". The agent writes the program and dry-runs it.
An **Approval request** card appears in the chat. It shows:
* The full program, with line numbers. Any script body sent to an RMM (PowerShell or Bash) appears as one readable block.
* **Flagged lines — read these twice** for lines that need a closer look.
* The write tools and **Clients** it covers.
* The **Validity** of the approval.
* An **Approval fingerprint** that identifies this exact program.
Select **Approve script** to run it, or **Deny** to stop it. Only a click on the card counts. Typing "approved" in the chat doesn't approve anything. The card expires if you don't decide within one hour.
Rallied runs the same program again with its writes turned on. When it finishes, Rallied posts a run report to the chat. The report lists each change per client and tool as done, already done, failed, or unknown. A change counts as made only once the report says **done**.
Only the person who asked for the script can approve, deny, or revoke it. That applies to platform admins too.
A few rules keep approved scripts safe:
* **The approval covers exactly what the card showed.** If the program tries another tool or another client, Rallied refuses that write and the program continues. The report lists it as outside the approval.
* **Writes are never repeated.** If the program runs again, changes it already made are skipped. A change marked **unknown** might have gone through. Rallied never resends it, so check it yourself.
* **Plan Mode pauses the run.** If your MSP switches to [Plan Mode](/agents/plan-mode), the approved script pauses until you return to Execute Mode.
* **Revoke at any time.** Select **Revoke** on the card to stop everything that would run under the approval. Deleting the thread also revokes it.
### How long an approval lasts
The agent picks a validity based on what you ask for. The card shows the one it picked:
| Validity | What it means |
| - | - |
| **Once** (default) | The program runs once on approval. It can schedule follow-up runs, such as checking RMM task results later, within 24 hours. |
| **Window** | You can ask the agent to run the program again without a new approval. The window lasts 24 hours by default and up to 7 days. |
| **Recurring** | The program runs on a schedule. See [Recurring scripts](#recurring-scripts). |
### Fixing an approved script
If an approved run fails, for example because of a wrong parameter, ask the agent to fix it. The agent dry-runs the corrected program and compares it with the approved one:
* If the fix stays within the same tools, clients, and connections, and doesn't change what is sent to a customer or person, Rallied applies it. Rallied then posts the difference to the chat and the run continues. Changes already made aren't repeated.
* Otherwise, a correction card shows only what changed. Select **Approve correction** to apply it.
## Recurring scripts
Ask for a schedule to have an approved script run on its own:
```text theme={"system"}
Every Monday, check every client's RMM devices for missing patches and
open a ticket for any device more than 30 days behind. Run it until the end of the year.
```
The card shows the schedule, for example "Recurring every Monday until **2026-12-31** (America/New\_York)". Schedules can run every few days, weekly, or monthly, and can last up to 12 months.
* The first run starts when you approve. After that, the same program runs each period on fresh data. It picks up new devices and, for approvals covering all clients, new clients.
* Each run posts its own report, including what's new since the previous run.
* The card lists past runs, and Rallied posts a notice in the thread seven days before the schedule ends.
* A recurring script can't be run on demand. Select **Revoke** on the card to stop all future runs.
## Scripts that read credentials
ConnectWise RMM task results can contain credentials, such as a BitLocker recovery key or a LAPS password. A script can read these results and save them to a file for you. When it does:
* The agent doesn't see the script's output. It gets only the status, file names, and row counts.
* The same applies if Rallied finds a credential anywhere in a script's output.
* The file is encrypted, only you can download it, and Rallied logs every download.
* Rallied deletes the file after 24 hours.
The agent never quotes or summarizes a credential. It also never asks you to paste one into the chat.
## Downloading files from Chat
Every file the agent shares appears as a **file card** under its message. This includes script CSVs and files the agent creates during the conversation. Select the download button on the card to save the file. The **Files** menu lists every file shared in the thread.
Files are only available to the person who owns the thread. They're kept for 30 days. Sensitive files are kept for 24 hours and labeled on the card:
| Card label | What it means |
| - | - |
| **Credentials · only you · 24 h** | The file contains credentials. |
| **Not scanned · only you · 24 h** | Rallied can't scan this file type, such as Excel, PDF, or images, so it treats the file as sensitive. Ask for CSV when you can. |
| **Too large (max 10 MB)** | Ask the agent to split the file. |
| **Couldn't save a copy** | Ask the agent to create the file again. |
| **Expired** | The file passed its retention period. |
If a file contains one of Rallied's own platform secrets, Rallied withholds it and doesn't store it.
## Limits
| Limit | Value |
| - | - |
| Run time for a script in the chat | 75 seconds |
| Run time for an approved script | 14 minutes |
| Scripts per chat message | 3 |
| Scripts running at once per MSP | 3, plus 1 approved script |
| Files per run | 20 files, 10 MB each |
If a script runs out of time, Rallied keeps the files written so far and marks them **partial**. Ask the agent to split the work into fewer clients per run.
## Related
* [Chat with your agent](/dashboard/chat) — where you ask for scripts and approve them.
* [Approval settings](/dashboard/policies) — the same tool policies apply to every script call.
* [Plan Mode](/agents/plan-mode) — pauses approved scripts for your MSP.
# Clients
Source: https://docs.rallied.ai/dashboard/clients
Give every company you support its own dedicated agent, scoped to their tenant and runbooks, then tune operating mode and context per client from one place.
A client is a company you manage IT for. Each client gets its own dedicated AI agent that picks up tickets from your PSA, runs against the client's Microsoft 365 tenant and runbooks, and handles IT requests on their behalf. Employees interact with the agent through your normal channels: a PSA ticket, a call to your helpdesk number, or (where you've connected one) a chat in Slack or Teams. They never see Rallied itself.
![The Clients list showing several client companies and their agent status]()
## Creating a client
Open your MSP in Rallied. You'll see a list of all your existing clients.
Click the **New Client** button. Enter the client's **name** (displayed in Rallied) and a **slug** (a short, lowercase identifier used internally, e.g. `acme-corp`). The slug must be unique across your clients and can only contain lowercase letters, numbers, and hyphens.
Click **Create**. The agent is provisioned automatically in the background; you don't need to trigger anything.
## The client detail view
Click any client's name to open its detail page. The detail view is organized into tabs:
![A client's detail page with its tabs and overview]()
Operating mode, agent status, and client management actions including delete.
Connect and manage third-party tools the agent can use for this client. Tool policies for each integration live on the integration's detail page.
A full audit log of every tool call the agent has made.
Client-specific prompt instructions layered on top of your MSP prompt.
Agent container health, logs, and resource usage for troubleshooting.
There is no top-level **Policies** or **Sessions** tab. Tool policies are configured per integration: open the integration from the Integrations tab. Conversation transcripts appear in the Activity log alongside tool calls.
## Client status
Two status fields appear on the Overview tab:
| Field | What it means |
| - | - |
| **Status** | The agent's current state: `active`, `provisioning`, `pending`, `creating`, `error`, or `destroyed` |
| **Deploy status** | The last config push: `idle`, `deploying`, or `error` |
When you create a client or update its integrations, the status moves through transitional states (`creating` → `provisioning` → `active`) while the agent is being set up. The page refreshes every 5 seconds, so status updates appear on their own.
If **Deploy status** shows an error, the error message appears below the badge so you can see what went wrong.
"Provisioning" means the system is setting up the agent container on your MSP's server. This usually takes under a minute and you don't need to do anything.
## Operating mode
Each client can run in one of three modes, configurable from the **Overview** tab:
The agent reads the request, analyzes it, and writes its plan as an internal note on the ticket, then stops. It never executes any actions. Use this when you want to evaluate the agent's judgment without it making changes.
The agent executes requests normally. For actions you've marked as needing approval, it asks a technician (and optionally a manager) to sign off before proceeding.
The client uses whatever operating mode you've set at the MSP level. This is the default for new clients. Changing the MSP-level mode updates all clients set to Inherit at once.
To change a client's mode, click the corresponding button on the Overview tab. The change takes effect on the next request the agent handles.
## Grouping clients into a workspace
The same company often lives in more than one of your systems: a record in your PSA, another in your RMM, maybe a third in a documentation tool, each with its own ID. By default Rallied creates one client row per source, which clutters your list with duplicates and, worse, means the agent can act on the wrong record when the systems disagree on the company's name.
A **workspace** groups those rows into a single client. One member becomes the **primary**: its agent, prompt, and settings handle every ticket, no matter which system the ticket came from. The other members keep their own identifiers so the agent can still reach the right record in each system.
Rallied picks the primary for you: a ticketing (PSA) member wins over an RMM member, which wins over any other source. Ties go to whichever member was created first. There's no manual override.
### Group clients together
In your Clients list, tick the checkbox on each row you want to group. All of them must be standalone clients, not ones already in a workspace.
![Three duplicate client rows (the same company synced from Hudu and ConnectWise, Microsoft 365, and Pax8) selected, with the "Group as one workspace" action bar at the bottom of the list]()
Click **Group as one workspace** in the action bar at the bottom of the list. A dialog shows the members you selected; give the workspace a name and click **Group clients**.
![The grouping dialog with a workspace name field and the selected members listed below it]()
The selected rows collapse into a single row under the primary's identity, marked with a group icon. The **Sources** column shows a logo for each system the workspace's members came from.
![The Clients list after grouping: one workspace row, with a source logo for every connected system, where there used to be three duplicates]()
To add another client later, select the workspace row and one or more standalone rows, then click **Add to \** in the action bar.
### Edit or dissolve a workspace
Open the workspace from the Clients list and go to the **Overview** tab. The **Workspace** section lists each member, tags the primary with a `PRIMARY` badge, and shows the member's identifier in each system it came from.
![A workspace's Overview tab showing the Workspace section with all three members, their identifiers in ConnectWise, Hudu, Microsoft 365, and Pax8, and the Dissolve workspace action]()
To remove a member, click the remove icon next to it. That client goes back to the list as a standalone row. To undo the grouping entirely, click **Dissolve workspace** at the top of the section and confirm; every member goes back to standalone.
Neither action deletes a client.
Each member keeps its own **Active** toggle, but activating any of them counts as one active client, so grouping never increases your bill.
### What the agent sees
When the agent picks up a ticket for a grouped client, it gets the full list of the client's identifiers: each member's system, ID, and company name exactly as that system spells it. The agent treats this list as the only valid mapping between systems, so it can find the right company in your RMM even when the ticket named it differently in your PSA.
## Deleting a client
On the Overview tab, click **Delete Client** at the bottom of the page. You'll be asked to type the client's name to confirm. Deleting a client permanently removes the agent, revokes all credentials, and cannot be undone.
# Documentation
Source: https://docs.rallied.ai/dashboard/documentation
Have the agent work from your team's real runbooks in Hudu, IT Glue, or Confluence, and cite the exact source page behind every answer it gives.
The agent doesn't work from a blank slate. On every ticket, it consults your team's actual documentation, the same runbooks, asset records, and how-tos your senior technicians would reach for, and shows you the exact source page for every claim it makes.
You connect documentation the same way you connect any other integration. Rallied keeps everything current in the background.
## What can be used as documentation
| Source | What the agent reads | Applies to |
| - | - | - |
| [Hudu](/integrations/hudu) | Companies, assets, articles, procedures, Central KB | Whichever client the ticket is for |
| [IT Glue](/integrations/itglue) | Documents, configurations, flexible assets, contacts | Whichever client the ticket is for |
| [Confluence](/integrations/confluence) | Pages and PDF attachments in the spaces you pick | All your clients |
Hudu and IT Glue documentation is **per-client**: when the ticket belongs to Foo Corp, only Foo Corp's documentation is used. Confluence documentation is **shared** across all clients: your team's institutional knowledge that applies the same way to every ticket.
## What your technicians see
On every ticket the agent works, the internal note it posts includes clickable citations back to the specific pages it drew from. If it decided a step based on a Hudu procedure, that procedure is linked in the note. If a Confluence runbook shaped the plan, that runbook is linked too.
Two things follow from this:
* **Trust, without babysitting.** Your technicians can verify any claim in one click instead of asking "where did the agent get that?"
* **Documentation debt shows up.** When the agent cites a runbook that's out of date, your technician sees it and can fix the source, which improves every future ticket that touches the same topic.
The agent also uses documentation implicitly, even when it isn't answering a direct question, by checking for client-specific quirks like:
* A non-standard SaaS reclamation process
* A preferred escalation path
* A group that can't be edited through the usual Microsoft 365 flow
## Getting started
You need at least one documentation source connected. The most common pattern:
* **[Hudu](/integrations/hudu)** or **[IT Glue](/integrations/itglue)** for per-client documentation: runbooks, passwords, configurations, asset records. Map each Rallied client to its Hudu company or IT Glue organization on the client's detail page.
* **[Confluence](/integrations/confluence)** on top of that for your team's shared playbooks, the ones that apply the same way across every customer.
Neither is required, but the agent gets meaningfully better once at least one is connected. Each integration page has full step-by-step setup.
## Managing your documentation
Every documentation integration has its own **Documentation** tab in **Settings → Integrations**. From there you can:
* See how much of that source is being used and how often the agent has cited it in the last 30 days
* Click **Sync now** to pull in your latest edits immediately, instead of waiting for the next scheduled refresh
* See when the source was last refreshed
The header of that tab also shows how often the agent has consulted your documentation overall in the last 30 days, so you can see the feature earning its keep.
## Keeping documentation fresh
Rallied refreshes automatically on a schedule and picks up new pages, edits, and deletions. You don't have to do anything to keep it current: as long as your team keeps writing in Hudu, IT Glue, or Confluence, the agent stays current with them.
If a page is deleted at the source, it drops out on the next refresh. If a page's read permissions no longer include your API-user, it's dropped too.
## Passwords and other sensitive content
Passwords are searchable by name (e.g. "VPN admin — Foo Corp") but never by value. When the agent actually needs to use a credential, it goes through your approval flow before it's revealed.
See [Hudu → Passwords and approval](/integrations/hudu#passwords-and-approval) and [IT Glue → Passwords and approval](/integrations/itglue#passwords-and-approval) for the specific approval defaults.
## See also
* [Hudu](/integrations/hudu)
* [IT Glue](/integrations/itglue)
* [Confluence](/integrations/confluence)
# Integrations
Source: https://docs.rallied.ai/dashboard/integrations
Turn on the tools your agent uses to actually resolve tickets: PSA, RMM, Microsoft 365, documentation, and more, with sensible approval defaults out of the box.
Integrations are the tools your agent uses to resolve IT requests: pick up tickets in your PSA, look up users in Microsoft 365, read runbooks in your documentation platform, run scripts through your RMM. Each integration you connect makes a set of tools available to the agent.
## Connecting an integration
Open **Settings → Integrations**. You'll see a grid of all available apps: PSA (ConnectWise, HaloPSA, Autotask), Microsoft 365, RMM (NinjaOne, Datto, ConnectWise Automate, ConnectWise RMM, N-central), documentation (IT Glue), and more.
Use the search bar or category filters to find the integration you want to connect. Apps already connected show a connected badge.
![The Integrations page listing available apps with Connect buttons]()
Click **Connect** on the app card. A sign-in window opens. Sign in to the service and grant Rallied access, or enter API credentials for integrations that use a credentials form.
After connecting, you're taken to the integration's detail page. Approval settings are pre-set with sensible defaults: reads are auto-approved, writes need approval. Review and adjust these before the agent starts handling requests.
Your credentials are only used to let the agent take the actions you've approved. They're never exposed anywhere else.
## What happens on connect
When you connect an integration, the actions that app offers become available to the agent with sensible defaults: reads run automatically, writes need approval. The agent starts using them straight away.
## Syncing companies from your PSA or RMM
Integrations that hold a list of companies — ConnectWise Manage, HaloPSA, Autotask, ConnectWise RMM, NinjaOne, N-central, and Pax8 — can pull those companies into Rallied as clients, so you don't have to create each one by hand.
Open the integration's detail page, go to the **Companies** tab, and click **Sync Companies**. A progress dialog runs the sync and closes when it's done. For each company found:
* **A new client is created** if no client with that company's identifier exists yet.
* **An existing client gains the integration as a new source** if the company already exists under a different system.
Only clients that come from a ticketing system (PSA) get an agent of their own. Clients created from an RMM or other source appear in your list but don't get an agent until you group them with a PSA client — see [grouping clients into a workspace](/dashboard/clients#grouping-clients-into-a-workspace).
You can re-run a sync any time. Existing clients are never duplicated; only new companies and new sources are added.
## Updating an integration's credentials
When you rotate an API key or client secret in a connected app, update it in Rallied instead of disconnecting and connecting again. Updating keeps the connection, so your approval settings, integration settings, synced clients, and approved scripts stay as they are.
Go to **Settings → Integrations** and open the connected integration. For an integration connected to a single client, open it from that client's page.
Click **Update connection** at the top of the page. The credentials form opens with your saved settings filled in.
Type the new secret, or the current one if it hasn't changed. Rallied never pre-fills secrets. Click **Update connection** to save. Rallied checks the new credentials with the app before saving them.
Only secrets can be changed this way. Other fields, such as a region or client ID, are read-only in the update form. To change one of them, disconnect the integration and connect it again.
**Update connection** appears only for integrations that are set up with a credentials form. It isn't shown for integrations connected through a sign-in window only, such as Microsoft Teams, or for [CIPP](/integrations/cipp), which has its own settings dialog.
## Disconnecting an integration
Click **Disconnect** on a connected app card (or from within the integration's detail page). A confirmation dialog tells you exactly what will happen — including how many clients will be deleted because that integration was their only source. On disconnect:
* The integration is removed and the connected account is revoked
* All approval settings for that app are cleared
* The integration is removed from every client's list of sources
* Any client left with no sources at all is deleted; clients that still have another source (a PSA record for the same company, say) are kept
This cannot be undone. If you reconnect the same app later, approval settings are seeded from defaults and you'll need to sync companies again.
Disconnecting clears all approval settings for that integration and may delete clients that only existed in that system. If you had customized any approval settings, you'll need to reconfigure them after reconnecting.
## Custom MCP servers
Bring the agent your own tools by adding a remote MCP server. Click **Add MCP Server** in the top-right corner of the Integrations tab.
Paste the HTTPS URL of the MCP server (e.g. `https://mcp.example.com/v1`). Local servers and plain HTTP are not supported. Click **Continue**. Rallied checks the server and figures out how it wants to be authenticated.
Depending on what the server requires, you'll see one of these options:
* **Sign-in** — a window opens for you to authorize the connection
* **Bearer token** — paste your API key or token
* **Custom header** — specify the header name and value
* **No auth** — the server is publicly accessible; no credentials needed
Give the connection a name (Rallied suggests one based on the URL).
Click **Connect** (or **Authorize** if a sign-in window is needed). The server's actions become available to the agent with sensible defaults.
Once connected, the custom MCP server appears alongside your other integrations, and its actions are available to the agent.
# Memory
Source: https://docs.rallied.ai/dashboard/memory
Turn the corrections your technicians make into lasting improvements: Rallied watches how tickets get resolved and proposes memories you can approve.
Memory is how your agent gets sharper on each client without you having to write anything down. After every ticket closes, Rallied compares what the agent planned with how a technician actually finished the job and quietly notes any correction that would matter next time. When the same correction shows up on a second ticket, it becomes a **memory proposal** in your review queue. You accept the ones that hold, dismiss the ones that don't, and decide whether each accepted memory applies to just that client or across your whole MSP.
The result is an agent that stops making the same mistake twice. Prompts and workflows are what you tell the agent; memory is what the agent notices on its own from watching your team work.
Memory is different from [documentation](/dashboard/documentation), [prompts](/dashboard/prompts), and [workflows](/dashboard/workflows). Documentation is what you already know, prompts are standing rules for every ticket, workflows are step-by-step playbooks for a kind of ticket, and memory is a small, specific correction the agent picked up from a real resolution.
You must be an MSP admin to accept or dismiss a memory.
## Where memories come from
When a ticket closes, Rallied compares what the agent planned with how the technician actually resolved it. If the two differ in a way that would matter next time, Rallied records the correction.
## Review the queue
Open **Memory** in the sidebar. The **Waiting for review** tab lists every promoted memory, along with the client it came from, how many times it has been seen, and the supporting tickets.
![The Memory page with the Waiting for review tab listing proposed memories, each with Accept and Dismiss]()
For each memory you have two choices:
* **Accept** starts applying it to that client's matching tickets. Accepting is one click and, by default, scopes the memory to the client it came from. You can widen the scope later.
* **Dismiss** discards the memory.
## Manage accepted memories
The **In the agent's memory** tab lists everything you've accepted. The agent consults these on tickets that match.
* **Change which clients it applies to.** Open **Applies to** on the memory and pick either the source client or **Every client in this MSP**. Widening the scope requires confirmation, because a correction learned in one client's environment may not hold in another's. Memories that apply everywhere are tagged **MSP-wide**.
* **Stop using it.** Click **Stop using it** and confirm. The agent stops applying the memory to new tickets, and the same correction won't be proposed again. This can't be undone.
## Memory, prompts, and workflows
Each tool is best for a different job:
| You want to | Use |
| - | - |
| Set a standing rule for every ticket | [Prompts](/dashboard/prompts) |
| Give the agent steps for a specific kind of ticket | [Workflows](/dashboard/workflows) |
| Keep a correction the agent learned on its own | Memory |
A memory is narrower than either a prompt or a workflow. If the same memory keeps surfacing for the same kind of ticket, it's probably a workflow in waiting.
## Related
* [Workflows](/dashboard/workflows) — write the playbook when a memory turns out to be a pattern.
* [Prompts](/dashboard/prompts) — standing instructions that apply to every ticket.
* [Execute Mode](/agents/execute-mode) — the mode a client must be in to produce memories.
* [Activity](/dashboard/activity) — see the tickets a memory was learned from.
# Performance
Source: https://docs.rallied.ai/dashboard/performance
See what the agent is really doing for your MSP: how often it works tickets, gets things done in your systems, and finishes with no technician involved.
The Performance page is your MSP-wide scoreboard for the agent. It tracks three rates over a rolling 7-, 30-, or 90-day window: **involvement** (how often the agent touched a ticket), **outcome** (how often it changed something in your systems), and **zero-touch** (how often it finished with no technician involved). Use it to see where the agent is pulling its weight, which clients are ready for more automation, and where Plan Mode is still holding things back.
## The three metrics
Open **Performance** in the sidebar. Pick a window: **Last 7 days**, **Last 30 days**, or **Last 90 days**.
Each card shows a percentage. It also shows the count behind it, as "N of M tickets received".
![The Performance page with the three rate cards, the involved tickets by day chart, and the per-client table]()
| Metric | What it counts |
| - | - |
| **Involvement rate** | Tickets the agent worked on. A plan, a note, or an action counts. |
| **Outcome rate** | Tickets where the agent changed something in your systems, or ran a workflow you wrote. |
| **Zero-touch rate** | Outcomes with no one from your team involved. |
All three rates use the same set of tickets: every ticket received in the window, minus tickets whose agent activity is not classified yet.
The metrics relate like this:
* Each zero-touch ticket is also an outcome.
* Each outcome is also an involved ticket.
* So involvement is the largest percentage, then outcome, then zero-touch.
Click a card to see the tickets behind it.
### Involvement
The agent did at least one successful thing on the ticket. A posted plan counts. An internal note counts.
### Outcome
The agent changed a system other than the ticket record. A password reset counts. An access grant counts. A workflow you wrote counts.
These do **not** count as an outcome:
* Notes
* Status changes
* Time entries
The ticket does not have to be closed.
### Zero-touch
The agent delivered an outcome. No person on your team touched the ticket after the agent's first change to your systems.
Work before that point does not stop the ticket from counting as zero-touch. Filing the ticket does not stop it. Assigning the ticket does not stop it.
## Reading the chart
**Involved tickets, by day** shows counts, not rates. Each bar is one day.
* The bottom segment is outcomes.
* The segment on top is tickets the agent touched with no outcome.
* The total on hover is every involved ticket that day.
## Per-client breakdown
If you have more than one client, a table below the chart shows **Client**, **Involved**, **Outcomes**, and **Zero-touch** as percentages for each client.
A client with no agent activity in the window shows **No agent activity yet**.
## Plan Mode and pending data
**Plan Mode.** In Plan Mode the agent diagnoses and posts a plan. It does not execute changes. Outcome rate and zero-touch rate come only from clients in Execute Mode. If no client is in Execute Mode, those two rates stay at zero. Involvement rate still counts the plans the agent posted. The page says this above the cards when it applies.
**Measuring since.** A card that shows **Measuring since** and a date is still collecting classified data. It does not show a zero until that data is ready.
## Related
* [Plan Mode](/agents/plan-mode) — why outcomes stay at zero until you switch a client.
* [Execute Mode](/agents/execute-mode) — the mode that produces outcomes and zero-touch resolutions.
* [Activity](/dashboard/activity) — the per-ticket log behind every count on this page.
* [Clients](/dashboard/clients) — switch a client's mode.
# Approval settings
Source: https://docs.rallied.ai/dashboard/policies
Decide exactly what the agent can do on its own and what needs sign-off, per action, so you get automation without ever losing control of sensitive work.
Every action Rallied's agents can take has an approval setting. You choose which actions run on their own and which the agent has to stop and get sign-off on before doing. Rallied enforces the rule; the agent can't work around it by rephrasing the request or trying a different action.
## The three settings
The agent runs the action without asking. Best for read-only work where you're happy for the agent to move on its own: looking up a user's profile, listing group memberships, reading a ticket, checking a device's alerts.
The agent stops, writes up exactly what it wants to do, and waits for a technician to approve or deny. The approval request lands on whichever channel the ticket is on: a PSA ticket note, a Slack DM, a Teams message. Best for anything that changes state, like resetting a password, adding a user to a group, rebooting a device, sending a customer-visible reply.
If the step includes a script the agent wrote itself, the approval also shows a plain-English analysis of what the script does. See [Script analysis on approval plans](/agents/execute-mode#script-analysis-on-approval-plans).
The action is hidden from the agent. Best for actions you never want the agent to use, such as deleting a user or account.
## Where to set them
Approval settings live on each integration's detail page. Go to **Settings → Integrations** and click into a connected integration. Every action that integration exposes has a dropdown next to it: pick the setting, click **Save**, and the change takes effect right away.
![An integration's policy table with per-tool permission dropdowns]()
Start conservative: after connecting a new integration, glance at the defaults and set anything unfamiliar to **Needs approval** until you've watched the agent handle it a few times.
## Requiring manager approval too
For anything set to **Needs approval**, you can add a second sign-off from the requester's manager. When manager approval is enabled on an action:
1. Your technician gets the usual approval request.
2. The requester's manager gets one as well.
3. Both have to approve before the agent proceeds.
Good for high-impact actions, like provisioning an admin account, granting access to a sensitive system. Toggle **Manager Approval** on the specific action's row on the integration page.
## Defaults when you connect a new integration
New integrations come pre-set with sensible defaults so you can turn them on without having to configure every action first:
| Kind of action | Default |
| - | - |
| Reads (looking things up, listing, fetching) | Auto-approve |
| Writes (creating, updating, deleting, adding, sending, resetting) | Needs approval |
These are starting points. Review them against how your team actually wants the agent to behave for each client.
## Related
* [Execute Mode](/agents/execute-mode) — how approvals play out once a client is live.
* [Rallied API](/api/talk) — approval settings also govern what the agent can do from an API conversation.
* [Identity Verification](/agents/identity-verification) — the MFA check that runs before sensitive actions.
* [Integrations](/dashboard/integrations) — where each integration's per-action settings live.
# Prompts
Source: https://docs.rallied.ai/dashboard/prompts
Teach the agent how you work: standing instructions on tone, conventions, and per-client environments so every ticket is handled the way your team would.
Prompts are the standing instructions your agent follows on every ticket: how you want it to communicate, which conventions to respect, and anything specific about a client's environment it should always keep in mind. Rallied composes each agent's system prompt from three tiers, a base prompt Rallied manages plus an MSP prompt and a per-client prompt that you write, so guidance you add once cascades to the right agents automatically.
## The three-tier prompt system
```text theme={"system"}
Base prompt (managed by Rallied)
└── MSP prompt (you write this)
└── Client prompt (you write this, per client)
```
The base prompt defines the agent's core IT helpdesk behavior: how to reason about requests, when to ask for clarification, how to use tools, approval flow logic, and safety rules. Rallied manages this prompt and updates it as the platform evolves.
You cannot edit the base prompt.
The MSP prompt is where you document your organization's IT policies and tool preferences. Every agent you run, across all your clients, receives this prompt in addition to the base prompt.
Use it for things like:
* "Use Microsoft 365 for user lookups, password resets, and group changes. For clients with a separate identity provider, prefer that provider for app-access decisions."
* "Escalate any request to create or modify admin-level accounts."
* "When a user reports a software issue, check if they've restarted within the last 24 hours first."
* "Our SLA for access requests is 4 business hours."
The client prompt adds context specific to one company. The agent receives it in addition to the base and MSP prompts.
Use it for things like:
* "This company uses Zendesk for customer support, Slack for communication, and Microsoft 365 for email and files."
* "Users are in the `clinic-staff` Microsoft 365 group. Contractors are in `clinic-contractors`."
* "The IT contact for escalations is [helpdesk@clinic.example.com](mailto:helpdesk@clinic.example.com)."
* "This client is a medical clinic: treat any patient data references with extra caution and do not store them in notes."
All three tiers are composed into a single system prompt that is deployed to the agent each time you save a change or update an integration.
## Editing the MSP prompt
Go to **Settings → Prompt** (or, as a platform admin, open your MSP's detail page and click the **Prompt** tab). Write your instructions in the editor and click **Save**.
![The Prompt page with the MSP prompt and admin agent prompt editors]()
The updated prompt is pushed to all your client agents automatically.
## Editing a client prompt
Open a client's detail page and click the **Prompt** tab. The editor shows only the client-level prompt. The base and MSP tiers are applied automatically and are not shown here.
Write your client-specific instructions and click **Save**. The change takes effect on the agent's next request.
![A client's Prompt tab with the client-level prompt editor]()
The Prompt tab shows a reminder that the agent receives both the MSP prompt and the client prompt. Avoid duplicating MSP-level rules in the client prompt; put shared standards in the MSP prompt where they apply to all clients.
## Tips for writing effective prompts
**Be specific about tool preferences.** Don't just say "use Microsoft 365". Say "use Microsoft 365 to look up users and manage group memberships. Use the `m365-get-user` tool to find a user before attempting any access changes."
**Document your escalation rules explicitly.** The agent will follow written rules more reliably than implied ones. If admin account creation should always go to a human, write: "Never create admin accounts autonomously. Always escalate to the on-call technician."
**Include company-specific context the agent can't discover on its own.** Things like org chart conventions, Microsoft 365 group naming patterns, your PSA board routing rules (which boards or queues take which request types), or the names of key applications employees commonly request access to.
**Keep MSP and client prompts focused.** The base prompt already covers general IT helpdesk reasoning. Your prompts should add what the base prompt can't know: your policies, your tools, your clients' environments.
After writing or updating a prompt, send a test request through your PSA (or the client's Slack bot, if connected) to verify the agent's behavior matches your expectations. Open the client's **Activity** tab to review the tool calls and agent reasoning.
# Restricting access to Rallied with IP allowlists
Source: https://docs.rallied.ai/dashboard/security
Lock Rallied sign-in to networks you trust, such as your office or VPN, using an IP allowlist of individual addresses or CIDR ranges. Agents are never affected.
You can limit access to your Rallied account to approved IP addresses, such as your office network or company VPN. Once you add IPs to the list, anyone who tries to open Rallied from a network that isn't on it will be blocked, even if their login is valid.
By default the list is empty and there are no restrictions.
IP restrictions only apply to people signing in. Your AI agents are never affected, and Rallied support can always reach your account to help you recover if you get locked out.
## Set up IP restrictions
You need to be an admin to change these settings.
Your current IP address is shown at the top of the page.
![The IP restrictions page with no entries added]()
Click **Add my current IP**. Do this first. If you saved a list that didn't include the address you're connecting from, you'd lock yourself out, so Rallied won't let you save until your own IP is on the list.
Click **Add IP / range** for each one. You can enter a single IP address or a range in CIDR notation:
```text theme={"system"}
203.0.113.10
203.0.113.0/24
2001:db8::/32
```
![The IP restrictions page with an IP address and a CIDR range added]()
The restriction takes effect immediately for everyone in your organization.
## Remove the restriction
Delete every entry from the list and click **Save**. An empty list means anyone with a valid login can access Rallied from any network.
## What blocked users see
Someone connecting from an unapproved network sees an "Access blocked from this network" page showing their current IP address. Signing out and back in won't help. To get back in, they can either:
* Connect from an approved network (for example, by turning on the company VPN), then reload the page.
* Ask an admin to add their IP to the list in **Settings → IP restrictions**.
If every admin is locked out, contact Rallied support and we'll fix the list for you.
# Workflows
Source: https://docs.rallied.ai/dashboard/workflows
Build step-by-step playbooks the agent follows on matching tickets. Describe one in plain English or start from a template, then edit steps and tools.
How to write step-by-step playbooks the agent follows on the tickets you see most.
A workflow has a **trigger** (one line describing which tickets it applies to) and a list of numbered **steps**. Each step has a short title, instructions, and the tools the agent can use for it. When a ticket matches an active workflow's trigger, the agent follows those steps instead of figuring the request out from scratch.
Find workflows under **Workflows** in the sidebar (used across all your clients), or on the **Workflows** tab of a single client (used only for that client).
## How workflows apply to tickets
Every time a new ticket comes in, the agent looks at your active workflows and picks the ones whose triggers describe the ticket. It follows those steps as its plan. If nothing matches, the agent works the ticket the way it normally would.
A few things to keep in mind:
* More than one workflow can apply to the same ticket. The agent considers every workflow that matches, whether it's shared or client-specific.
* Matched steps are the plan, not a suggestion. The agent follows them as written rather than improvising. If a step is wrong, edit the workflow.
* The agent matches on the **trigger**, not the steps. A vague trigger means missed matches; a too-broad one means the workflow runs on tickets it wasn't meant for.
* Only **active** workflows are used. Drafts and archived workflows are ignored.
## Workflows for all clients vs. a single client
You can create a workflow that applies to every client you support, or one that only applies to a single client.
| Where you create it | Who it applies to |
| - | - |
| **Workflows** in the sidebar | Tickets for any of your clients. Shows as **MSP-wide** in the **Scope** column. |
| **Workflows** tab inside a client | Only that client's tickets. |
Start with shared workflows for anything that's true across your clients, like onboarding, password resets, and ticket triage. Add a client-specific workflow when one customer's setup needs a different sequence, like an offboarding flow that reclaims a non-standard SaaS license.
An active workflow can be promoted to all clients. You can't move an MSP-wide workflow back to a single client. Create a new client workflow instead.
### Promoting a client workflow to all clients
When a client workflow works well and fits your other clients too, promote it instead of rebuilding it. The workflow keeps its run history and its link. Every client's agent picks it up as an MSP-wide workflow.
You need permission to edit workflows. The workflow must be active.
1. Open the client workflow and save or discard any unsaved edits.
2. Click **Promote to all clients**. Rallied opens a preview of what changes.
3. Review the preview, then click **Promote to all clients** to confirm.
The preview lists:
* **Runs without approval on every client**: tools the workflow pre-approves once it applies to every client.
* **No longer pre-approved**: tools that lose pre-approval under your MSP-wide [approval settings](/dashboard/policies). A technician approves these again.
* **Scripts that run on their own on every client**: auto-run scripts that will run on every client without a technician.
* **Auto-run turns off**: scripts that will wait for a technician again.
Rallied blocks the promotion if the workflow uses tools that aren't connected for your whole MSP. It also blocks workflows that point to other workflows used by only one client. Connect those tools MSP-wide, or promote the other workflows first, then try again.
If the workflow has scripts that run on their own, only an MSP admin can promote it. If something changes while the preview is open, Rallied shows an updated preview for you to confirm again.
## Creating a workflow
You need permission to manage workflows. The built-in MSP Admin role has it; MSP Technicians can view workflows but not change them.
From the **Workflows** page, click **New workflow**. You can describe the workflow in your own words or start from a template. Either way, Rallied creates a draft and opens it in the editor.
![The New workflow dialog with a description box and starter templates]()
### Describe it in your own words
Under **What should this workflow do?**, describe what kind of ticket it's for and what the agent should do about it. Click **Generate workflow**. Rallied matches your description to the tools you've connected and builds a trigger and steps for you to review in the editor.
Examples that work well:
* **"When a new hire starts, create their Microsoft 365 account, assign their license, and add them to the engineering distribution list."**
* **"When a ticket reports a stuck print job, restart the printer's print spooler service and add an internal note with the result."**
* **"When a security alert ticket comes in about a suspicious sign-in, check the user's recent sign-in activity, decide whether it's benign, suspicious, or compromised, and post the verdict as an internal note."**
Press **`⌘ / Ctrl + Enter`** in the description box to generate without clicking.
### Start from a template
Under **Or pick a template**, click a template. Each one comes with a trigger and steps already written, so you get a working draft right away. Templates cover the most common kinds of tickets:
| Category | Templates |
| - | - |
| **Triage and routing** | Assign to lowest-loaded technician · Enrich with requester context · Categorize and route |
| **Microsoft 365 user lifecycle** | Onboard new hire · Offboard departing employee · Reset password · Group / distribution list membership · Shared mailbox access · Recommend license upgrade |
| **Ticket actions** | Update ticket status |
| **Security** | Reset locked accounts · Investigate suspicious sign-in |
| **Scheduling** | Send TimeZest scheduling link |
Templates work across ConnectWise, HaloPSA, and Autotask. The agent uses whichever ticketing system you've connected.
If a template needs an integration you haven't connected yet, it shows a **Requires** hint, like **Requires TimeZest**. Connect that integration in **Settings → Integrations** so the workflow's tools are available.
### If you haven't connected anything yet
You can't create a workflow until you connect at least one integration; the agent needs tools to work with. Click **Go to integrations** in the dialog. Connect Microsoft 365 to unlock the user-lifecycle templates, or ConnectWise, HaloPSA, or Autotask to unlock the ticket templates.
## Editing a workflow
Click any workflow in the list to open the editor. The editor is a split view with chat on the left and the workflow document on the right. On narrow screens, use the **Chat** and **Workflow** buttons at the top to switch between the two panes.
The chat is the primary way to build or change a workflow. Type what you want in **Ask Rallied to change this workflow…**, like "add a step that emails the requester when the reset is done." Rallied updates the draft beside the conversation and marks changed cards as **Updated**. Review the changes, then save.
The right pane shows a map of your workflow:
* **Title**: click the **Rename** pencil next to the name to edit it. New workflows created from a prompt get a generated name based on the workflow's content, not a copy of your prompt text.
* **Trigger**: click the **Trigger** card and fill in **Trigger conditions**. Keep it to one line (280 characters at most).
* **Steps**: click a step to edit it.
### Adding and removing steps
Click **Add next step** at the bottom of a step list to add a new step. Use the arrows at the top of a step's inspector panel to reorder it, or the trash icon to remove it.
### Adding an If/Else
Click **Add If/Else** (the icon with a merge symbol) to add a decision point after any step. An If/Else has a plain-English **Condition**, a **YES** path, and a **NO** path. The agent evaluates the condition and follows only the matching path. Each path is its own list of steps that ends the workflow. If neither path matches, the workflow ends.
A few things to keep in mind:
* The condition is a single sentence, 500 characters at most, written the same way you write step instructions.
* You can nest If/Else steps up to 3 levels deep.
* Each path can hold up to 100 steps total across the whole workflow.
* The agent decides which path fits the ticket. Nothing server-side enforces the choice.
* The workflow grant covers every tool referenced in any path, whichever one runs.
To add a second condition, add another If/Else in the NO path of the first one. To remove an If/Else, select it and click **Remove If/Else**. Rallied asks whether to keep the YES steps or the NO steps in its place.
### Editing a step
Each step has a title, instructions, and tools.
* **Title**: a short label, 60 characters at most. Put the detail in the instructions.
* **Instructions**: include the action, the evidence to collect, and when the agent should stop.
* **Tools**: the actions this step can use from your connected systems.
To add a tool, click **Add a tool** and search by name or system. Tools marked **Requires approval** normally need a technician's sign-off before they run.
![The Add a tool search listing matching actions from ConnectWise Manage]()
### Script auto-run
Some steps run a script the agent writes itself. For qualifying tools, you can turn on **Run on its own when the script passes review** in the step inspector. When enabled, scripts that pass the safety checks run without waiting for a technician. Anything the checks don't clear still goes to a technician for approval. Nothing is ever refused.
This setting applies to every step in the workflow that uses the same tool. The switch shows an **Applies to every step in this workflow that uses this tool** note when the tool appears on more than one step.
Qualifying tools are script runners where the agent writes the script itself:
* ConnectWise RMM PowerShell script runner
* ConnectWise RMM Bash script runner
* NinjaOne Bash runner
CMD scripts and runners where the language is unknown never qualify for auto-run. Library-script runners (where an admin puts the script in the RMM first) are not affected.
The checks run in this order:
1. **Device scope**: exactly one target device.
2. **Language**: PowerShell or Bash only. CMD escalates to a technician.
3. **Safety screening**: the screening looks for credential access, account changes, security control changes, installers, and other high-risk operations. Anything flagged goes to a technician.
4. **Independent review**: an isolated reviewer checks whether the script's effects match what the workflow step describes. The reviewer only sees the workflow text, the effects list, and the script itself. No ticket data reaches it.
Trusted download sources are configured in **Settings → Security**. Add URLs or UNC paths your scripts need to download from.
Only an MSP admin can turn auto-run on or publish workflow text changes while auto-run is active. Anyone can turn it off.
Auto-run activity shows in **Run history** and appears in [Activity](/dashboard/activity). For details on the script analysis shown on approvals, see [Execute mode](/agents/execute-mode).
### Saving and turning a workflow on
Edits aren't saved automatically. Click **Save** when you're done.
* **Draft workflow**: **Save** keeps your changes as a draft. Turn on the **Active** switch to start using it on tickets.
* **Active workflow**: **Save** publishes your changes right away. The agent uses them on the next matching ticket.
You can't turn on a workflow until it has a trigger and every step has a title and instructions. Steps missing either show a **Needs title** or **Needs instructions** pill.
Turning on a workflow pre-approves the tools in its steps. When the agent runs that workflow, tools marked **Requires approval** run without asking a technician first. Review every step's tools before you turn a workflow on or save changes to an active one.
Scripts the agent writes itself are only pre-approved when the step's auto-run switch is on and the script passes the safety checks. Without auto-run, or when a check doesn't clear, the script goes to a technician for approval. Nothing is ever refused.
If another admin saves the same workflow while you're editing, Rallied asks whether to load their version or reapply your changes on top of it.
Chat is unavailable while you have unsaved inline edits. Save or discard your inline changes first.
### Writing a good trigger
The trigger matters more than anything else on a workflow. The agent decides which workflows to use based on the trigger alone, so a sloppy trigger leads to either missed matches or workflows firing on the wrong tickets.
Tips for writing a good trigger:
* Start with **when**, and describe the **situation**, not the **action**. **"When an offboarding request comes in for a departing employee"** is better than **"Offboard the user"**.
* Name the kind of ticket or signal you're looking for, like a request, an alert, or a status change.
* Stick to **what kind of ticket this is**. Leave the **how** for the steps.
If you can't write a clean one-line trigger, the workflow is probably doing two things and should be split.
### Workflows created before steps
Workflows written as a single block of instructions are converted into steps the first time you open them. Each numbered line becomes a step. Nothing changes for the agent until you save.
If a workflow can't be converted, the editor shows the original text read-only with the reason, like an integration that isn't connected or instructions with no numbered steps. Fix the reason given, like connecting the integration, to edit it. You can still turn it on or off.
## Workflow status
The workflow exists but the agent doesn't use it yet. Drafts are for composing, editing, and reviewing before going live.
The agent uses this workflow on matching tickets. Turn the **Active** switch off to return it to a draft.
The workflow is retired and the agent won't use it. Workflows created before steps are archived when you turn them off. Turn the **Active** switch back on to restore one.
Filter the list by status with the **All statuses** menu.
## Seeing which tickets used a workflow
Open the workflow and click the **Run history** tab. It lists the tickets where the agent ran at least one step of that workflow.
![The Run history tab listing tickets, clients, steps run, and outcomes]()
Each row shows the ticket, the client, how many steps ran, the outcome, and when the workflow last ran on it. The **Outcome** column counts actions that were **pre-approved** by the workflow, **changes** the agent made, and actions that **failed**. Click a row to open the ticket. Use this list to confirm a new workflow is triggering on the tickets you meant it for.
## Deleting a workflow
From the list, click the trash icon on the row and click **Delete**.
Deletion is permanent. If you might want the workflow back later, turn it off instead.
## Tips
* **Start with a template.** They're a faster, cleaner starting point than a blank page.
* **Turn workflows on one at a time.** That way if the agent's behavior changes, you know which workflow caused it.
* **Watch the first few tickets after activating.** Check **Run history**, then open a few tickets in **Activity** and skim the agent's plan. If the trigger caught the wrong tickets, tighten it; if a step got skipped, edit the instructions.
* **Don't go overboard with client-specific workflows.** They're useful when a single client genuinely needs a different sequence, but a pile of one-off client workflows is harder to maintain than a single well-written shared one.
## Related
* [Prompts](/dashboard/prompts) — standing instructions that apply to every ticket.
* [Memory](/dashboard/memory) — corrections the agent learned on its own, which often point to a missing workflow.
* [Activity](/dashboard/activity) — check what the agent did on the first tickets a workflow matched.
* [Integrations](/dashboard/integrations) — the tools a workflow's steps can use.
* [Approval settings](/dashboard/policies) — which tools need a technician's sign-off outside a workflow.
# Introduction
Source: https://docs.rallied.ai/index
What Rallied is, who it's for, and how MSPs use an AI technician to clear L1 helpdesk tickets across PSA, RMM, Microsoft 365, and documentation tools.
Rallied is the AI technician that lives inside your PSA, reads incoming tickets, and executes fixes across your full stack: ConnectWise, HaloPSA, or Autotask for ticket intake and approvals; Microsoft 365 for identity and mailbox work; your RMM and documentation tools (Hudu or IT Glue) for everything else. Nothing for your team to build and nobody you need to hire to admin it. You're running in days, not months.
## What it does
When a ticket lands in your PSA, the agent picks it up automatically:
* Diagnoses the request
* Looks up the user in Microsoft 365 and checks your runbooks
* Either resolves the issue directly or pauses for technician approval based on the policies you set
Every step the agent takes is posted as a note on the ticket, so your team gets a complete audit trail of what ran, when, and for whom without leaving the PSA.
## Who it's for
Rallied is built for **Managed Service Providers (MSPs)**. If your team supports multiple client companies and you're tired of L1 swallowing your senior techs' time, you get a dedicated AI technician per client without building or maintaining any bot infrastructure yourself.
## How accounts are organized
```text theme={"system"}
Your MSP (you)
└── Clients (the companies you manage)
```
* **MSP** — your organization. You connect your PSA, Microsoft 365, RMM, security, and documentation tools once at this level. Every client inherits these connections.
* **Client** — each company you manage IT for gets its own agent, scoped to their tenant, their tickets, and their runbooks. Configuration never leaks between clients.
## What's in the agent's toolbox
Once you connect integrations, the agent can:
* **Pick up and resolve PSA tickets** in ConnectWise, HaloPSA, or Autotask — read the ticket, post diagnostic notes, update status, request approvals from your techs, and reply to the customer
* **Manage users in Microsoft 365** — reset passwords, unlock accounts, change group membership, assign licenses, manage mailbox rules
* **Read your client documentation** in Hudu or IT Glue so it answers the way your senior techs would
* **Run on the endpoint** through your RMM (NinjaOne, Datto, ConnectWise Automate, Atera, Kaseya)
* **Verify identity** via MFA push before any sensitive action runs
* **Route approval requests** to the right technician, and to the employee's manager when an action calls for it
You decide how much autonomy the agent has. For each tool you set a policy: auto-execute, require approval, MSP-only, or disabled.
## Augments your techs, doesn't replace them
The agent takes the repetitive Level 1 work — password resets, access grants, account unlocks, basic onboarding — so your senior technicians can spend their time on Level 2, Level 3, and project work. Start in **Plan Mode** to watch the agent reason about real tickets without acting, then switch to **Execute Mode** when you trust its judgment.
***
Connect your PSA, Microsoft 365, and docs platform using the guided setup wizard. First client live in under fifteen minutes.
Every tool the agent can use — PSA, RMM, identity, security, docs, and more.
Ask questions, kick off actions, or work a ticket together from Rallied or inside ConnectWise.
Plan Mode for safe rollout. Execute Mode for live execution with policy-based gates.
Ask your agent about any ticket from your own scripts and automations.
# Autotask
Source: https://docs.rallied.ai/integrations/autotask
Have the agent live in Datto/Kaseya Autotask: pick up new tickets, post its work as notes, and run approvals in-ticket without technicians switching tools.
Connect Autotask and Rallied's agents pick up new tickets and notes automatically. Each ticket lands on the right client, and the agent starts with the context your technicians would otherwise have gathered themselves.
Autotask is configured in **Settings → Integrations**.
## How to connect
Autotask uses API user credentials plus an API tracking identifier. Rallied auto-detects your datacenter zone from the username.
In Autotask, go to **Admin → Resources/Users → API Users → New**. Create an API user, generate a **Secret**, and assign an **API Tracking Identifier** (a 26-character code). Note the username, secret, and tracking identifier. The secret is only shown once.
In Rallied, go to **Settings → Integrations**.
Find the Autotask card and click **Connect**. A credentials form appears.
Fill in:
* **Username** — the API user (e.g. `apiuser@yourmsp.com`)
* **Secret** — the API user's secret
* **API Tracking Identifier** — the 26-character tracking code
Click **Save**. Rallied figures out which Autotask zone you're in and validates the credentials.
After saving, the **Select company types to import** step opens. Pick which Autotask company types (e.g. **Customer**, **Lead**) should be imported as Rallied clients. New clients are provisioned with an agent automatically.
Autotask doesn't expose webhook registration via API for all entities, so Rallied generates the webhook URL and shared secret on the integration detail page. Copy them into Autotask under **Admin → Extensions & Integrations → Outbound Integrations** for the **Ticket** and **TicketNote** entities. The card shows **Connected** once Autotask sends its readiness GET ping.
## What happens when a ticket comes in
When a new ticket or note lands in Autotask, the agent picks it up right away, matches it to the right client, and starts working. There's nothing for your dispatchers to do.
If you've set up [workflows](/dashboard/workflows) that match the incoming ticket, the agent follows your instructions for that scenario.
### Sensitive tickets and identity verification
If a ticket is classified as sensitive (a password or MFA reset, for example) and you have a verification provider like [Traceless](/integrations/traceless) connected, Rallied sends the requester an identity verification challenge before the agent starts work. The agent pauses until the verification resolves, then posts an internal note on the ticket with the outcome, so technicians always see whether the requester approved, denied, or let the request expire.
## Approving an action without leaving Autotask
When the agent's plan needs a technician's sign-off, it posts an internal note on the ticket describing what it wants to do, with approve and deny links right in the note. Your team approves or denies from Autotask.
Only the ticket's assigned resource can approve. Replies from anyone else are treated as normal messages and don't affect the approval.
## What the agent can do in Autotask
**Runs automatically**
* Read tickets, notes, statuses, priorities, and queues.
* Look up companies, contacts, technicians, and configuration items (assets).
* Add internal notes visible only to your team.
* Adjust classification and routing fields (priority, status, queue, assignee, ticket type).
**Needs approval**
* Update a ticket's status, priority, assignment, queue, or resolution.
* Post a customer-visible reply (disabled by default; enable it per client when you're ready).
The agent can also reach any Autotask endpoint through a generic API tool when the built-in ones don't cover something. Reads run automatically; writes go through approval.
## Approval settings
See [Approval settings](/dashboard/policies) for an overview. Per-tool settings live on the Autotask detail page (open it from **Settings → Integrations**).
# Axcient x360Recover: read backup health from tickets
Source: https://docs.rallied.ai/integrations/axcient
Connect Axcient x360Recover so the agent can check device backup health, restore points, vault replication, and job runs when an Axcient alert hits a ticket.
Connect Axcient x360Recover and the agent can answer backup questions straight from a ticket. Ask **"is FILE01 backing up again?"** or **"why did the vault replication alert fire for Acme?"** and the agent reads the device's real backup state from Axcient. The integration is read-only. Rallied never changes anything in Axcient.
Axcient x360Recover is configured in **Settings → Integrations**.
## What you get
* **Backup triage from inside the ticket.** The agent checks a device's current health status, why it changed, and since when.
* **Restore point checks.** The agent sees the latest successful local, cloud, and vault restore points, plus the protection thresholds they're measured against.
* **Job history.** The agent lists a device's backup and vault replication jobs and the recent runs of each, including the error message of a failed run.
* **Appliance status.** The agent checks whether a client's on-site backup appliances are online, and whether their tunnel is up.
## How to connect
Sign in to the Axcient x360Portal (`partner.axcient.com`) as an administrator. Open **Settings → API Keys**, click **Add API Key**, and copy the key. Axcient shows it only once.
In Rallied, go to **Settings → Integrations**.
Find the Axcient x360Recover card and click **Connect**. Paste the key into **API Key**.
Click **Save**. Rallied validates the key and syncs your Axcient clients. The card shows **Connected** when it's ready.
One API key covers every client in your Axcient organization.
## Mapping Axcient clients to Rallied clients
When you connect, Rallied syncs your active Axcient clients and matches each one to a Rallied client. Inactive Axcient clients are skipped. Review the matches on the **Axcient clients** tab of the integration's detail page. Click **Sync clients** to pick up clients you've added in Axcient since.
On a client's ticket, the agent only reads that client's Axcient data. It fills in the client's Axcient ID by itself, so it never has to look it up.
Listing every Axcient client, or devices across all clients, is limited to the MSP admin [Chat](/dashboard/chat). Use it for fleet-wide questions such as "which clients have troubled backups right now?"
## How the agent uses it
When an Axcient alert or backup question lands on a ticket, the agent typically:
1. Lists the client's protected devices to find the one named in the alert.
2. Opens the device to read its current health status, thresholds, and latest local, cloud, and vault restore points.
3. Lists the device's jobs and reads the recent runs of the failing one, including the error message.
4. Checks the client's appliances if the alert points to an offline appliance or a down tunnel.
Health statuses come straight from Axcient: `NORMAL`, `WARNED`, `TROUBLED`, `UNPROTECTED`, and `PARKED`.
## Tools
| Tool | Default policy | Description |
| - | - | - |
| `axcient:axcient-list-clients` | Auto | List every Axcient client with its backup health and protected-system counts (admin chat only) |
| `axcient:axcient-list-devices-all-clients` | Auto | List protected devices across all clients with their backup health (admin chat only) |
| `axcient:axcient-get-client` | Auto | Get one client's overall backup health, protected-system counts, and appliances |
| `axcient:axcient-list-devices` | Auto | List one client's protected devices, optionally only direct-to-cloud (D2C) devices |
| `axcient:axcient-get-device` | Auto | Get one device's health, thresholds, latest restore points, vaults, and jobs |
| `axcient:axcient-list-device-jobs` | Auto | List a device's backup and vault replication jobs |
| `axcient:axcient-list-job-history` | Auto | List a job's recent runs, filtered by status or the last N hours |
| `axcient:axcient-list-appliances` | Auto | List a client's on-site appliances with health, tunnel status, storage, and version |
## Policies
Per-tool policies are configured on the **Axcient x360Recover** integration detail page (open it from **Settings → Integrations**).
See [Approval settings](/dashboard/policies) for an overview.
# CIPP
Source: https://docs.rallied.ai/integrations/cipp
Skip per-tenant clicking: with CIPP connected, Rallied pushes admin consent into all your Microsoft 365 customer tenants on its own and uses Exchange tools through CIPP.
Connect CIPP (CyberDrain Improved Partner Portal) and Rallied pushes admin consent into all your Microsoft 365 customer tenants on its own, and uses Exchange tools in tenants where the Rallied app doesn't hold the Exchange Administrator role.
CIPP is a companion to the [Microsoft 365 integration](/integrations/microsoft-365) — connect Microsoft 365 first. Without CIPP, Microsoft 365 still works fully: you approve consent yourself, one click per tenant, and Rallied handles the roles ([Microsoft 365, Phase 3](/integrations/microsoft-365#step-2-choose-how-rallied-gets-access)).
## What it saves you
If your MSP already runs [CIPP](https://docs.cipp.app), connecting it is the fastest way to get every customer tenant ready:
* **Admin consent is pushed for you.** The moment you connect, Rallied pushes consent into every tenant still waiting; every later **Sync from Microsoft** does the same for new tenants. Nothing to click per tenant. A tenant that isn't in CIPP's **Tenants** list reads **Not in CIPP** and is never pushed; its **Grant admin consent** opens the Microsoft consent page directly.
* **Exchange tools without assigning the Exchange Administrator role per tenant.** The agent picks up distribution groups and shared mailboxes through CIPP automatically; with CIPP connected, the Exchange Administrator role is not part of a tenant's status.
* **SharePoint restores and site access.** The agent can restore deleted SharePoint and OneDrive items (CIPP 10.6.0 or later) and grant access to a SharePoint site or library (CIPP 10.9.0 or later). Microsoft Graph can't do either. See [SharePoint and OneDrive](/integrations/microsoft-365#sharepoint-and-onedrive).
* **User changes without a directory role.** If Microsoft refuses a password reset, enable/disable, or deletion with a 403 because the Rallied app has no role in that tenant, Rallied retries it through CIPP.
[Mailbox forwarding and inbox rule tools](/integrations/microsoft-365#email-forwarding-and-inbox-rules) don't route through CIPP yet. To use them in a tenant, the Exchange Administrator role has to be on the Rallied app directly ([Microsoft 365: assign the roles manually](/integrations/microsoft-365#alternative-assign-the-directory-roles-manually)).
## How to connect
In your CIPP instance, go to **Integrations → CIPP-API**, then **Actions → Create New Client**. Name it something like `Rallied`, give it the **admin** role (Rallied pushes admin consent and runs Exchange actions through this client, so a restricted role would make CIPP reject those calls) and **enable the client**; IP ranges and MCP access can stay as they are. Afterwards click **Actions → Save to Azure** so CIPP's function app accepts the new client (the Tenant ID on that page can take 5 to 15 minutes to populate).
The CIPP-API page gives you four values to copy:
* **CIPP API URL** — the URL of your CIPP instance (e.g. `https://cipp-xxxxx.azurestaticapps.net`, or your custom domain)
* **Tenant ID** — the Microsoft tenant hosting your CIPP deployment
* **Client ID** — the Application (Client) ID from the Entra ID app registration CIPP created
* **Application Secret** — shown by CIPP once, when you create the client
Copy the **Application Secret** right away. CIPP only shows it once. If you miss it, generate a new one in **Entra ID → App registrations → \[your CIPP API app] → Certificates & secrets**.
Go to **Settings → Integrations**, find the **CIPP** card, and click **Connect**. Paste in all four values and click **Connect** again. Rallied checks the credentials with CIPP before saving. If anything's wrong, you'll see an inline error.
As soon as CIPP is connected, Rallied pushes admin consent into every tenant still marked **Not yet consented** that CIPP manages (it checks CIPP's **Tenants** list first). Rows turn **Processing…** and then **Ready** on their own (CIPP applies grants in the background, so this can take a few minutes; Rallied waits 15 minutes, then looks again an hour later and on its daily check). A tenant that isn't in CIPP's list reads **Not in CIPP** instead: add it to CIPP, or approve it yourself from the row. Tenants that already had consent are routed through CIPP for Exchange on Rallied's next check (once a day) or on the next Sync. No further setup needed.
## Editing or disconnecting
Edit any field from the CIPP detail page. Leave **Application Secret** blank to keep the existing one; type a new value to rotate it.
To disconnect, click **Disconnect**. When you do:
* Rallied stops pushing consent through CIPP, and tenants that were using CIPP for Exchange read **Finishing setup…** or **Needs access method** until the Exchange role is in place another way.
* Consent already granted stays granted. For new tenants, switch to **Approve yourself** in the Companies tab guide ([Microsoft 365, Phase 3](/integrations/microsoft-365#step-2-choose-how-rallied-gets-access)); Rallied then assigns the Exchange role itself, or you can [assign it manually](/integrations/microsoft-365#alternative-assign-the-directory-roles-manually).
* Everything else (user, password, and group management) keeps working as before.
## Troubleshooting
The secret CIPP gave you has likely expired or been rotated. Generate a fresh one in Entra ID → **App registrations → \[your CIPP API app] → Certificates & secrets**, paste it into the CIPP detail page, and click **Save changes**.
The tenant isn't in CIPP's **Tenants** list (or is marked excluded there), so Rallied doesn't ask CIPP to approve it. Add the tenant to CIPP with an active GDAP relationship and Rallied pushes the approval on its next check, or approve it yourself: **Grant admin consent** on the row opens the Microsoft consent page directly, to approve as a Global Administrator of that tenant.
CIPP accepted Rallied's request and nothing landed. Hover the status: it says when Rallied asked. The reason is in CIPP's logbook (**Logs**, API "Add Multitenant App"): typically no working GDAP relationship with that tenant, or a GDAP role set that can't create applications. Fix it on the CIPP side — Rallied looks again an hour later and on its daily check — or approve the tenant yourself from the row, which opens the Microsoft page directly once a CIPP push has gone nowhere.
With CIPP connected, directory roles are not part of a tenant's status, so this is never about the Exchange Administrator role. The suffix means the tenant approved Rallied's app before a permission was added and CIPP is re-applying the approval; everything already approved keeps working. If it stays, CIPP couldn't apply it: check that the tenant is in CIPP's **Tenants** list with a working GDAP relationship, or click **Grant admin consent** on the row and approve again in the Microsoft page.
## See also
* [Microsoft 365](/integrations/microsoft-365) — the integration CIPP accelerates
* [CIPP documentation](https://docs.cipp.app)
* [Setting up the CIPP API integration](https://docs.cipp.app/setup/api)
* [Integrations overview](/integrations/overview)
# Confluence
Source: https://docs.rallied.ai/integrations/confluence
Turn your Confluence into the agent's playbook: it consults your shared runbooks on every ticket and cites the exact page behind each recommendation.
Connect Confluence and the agent works from the runbooks and how-tos your team already keeps there. On every ticket, the agent's internal note links back to the Confluence page behind each claim, so your technicians can check the source in one click.
Confluence is configured in **Settings → Integrations**.
## What it's for
Confluence content is **shared across all your clients**: your team's institutional knowledge, not per-customer documentation. Pick the spaces you want the agent to read, and every client's tickets can draw on them.
For per-customer documentation (client-specific runbooks, passwords, asset records), connect [Hudu](/integrations/hudu) or [IT Glue](/integrations/itglue). Those tools store one workspace per client, and the agent stays scoped to whichever client the ticket belongs to.
## How to connect
Sign in to Atlassian at [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens) and click **Create API token**. Give it a recognizable label (e.g. `Rallied Integration`) and copy the token. It's shown only once. Both classic and scoped tokens work.
In Rallied, go to **Settings → Integrations**.
Find the Confluence card and click **Connect**. A credentials form appears.
Fill in:
* **Site name** — the subdomain before `.atlassian.net`. If your Confluence URL is `mycompany.atlassian.net`, enter `mycompany`.
* **Atlassian account email** — the email of the account that owns the API token.
* **API token** — the token you generated above.
* **Space keys** — a comma-separated list of the space keys you want the agent to read (for example, `ENG,DOCS,KB`). Only these spaces are used.
Click **Save**. Rallied validates the credentials, pulls in your pages, and the card shows **Connected** when it's ready. Pages with read restrictions are skipped automatically.
Only include the spaces you actually want the agent using. If your Confluence has a mix of engineering runbooks, HR policies, and marketing wikis, list just the operational spaces.
## What your technicians see
Every internal note the agent posts on a ticket includes clickable citations back to the exact Confluence page(s) it used. Technicians open the note, see the plan, and click straight through to the source. Outdated runbooks get spotted (and fixed) fast.
Confluence pages aren't tagged by client. They're treated as MSP-wide knowledge that applies to every ticket.
## Which pages are used
* Pages in the spaces you listed.
* **PDF attachments** on those pages — vendor guides and RFPs your team keeps attached to Confluence pages are used the same as the page text.
* Pages you haven't restricted — anything your API-token user can read.
Skipped: pages with read restrictions the API-token user doesn't satisfy, spaces you didn't list, and archived spaces.
## Keeping content fresh
Rallied refreshes on a schedule and picks up new pages, edits, and deletions automatically. If you've just made a big batch of edits, click **Sync now** on **Settings → Integrations → Confluence** to pull them in immediately.
## Editing what's included
Open **Settings → Integrations → Confluence** to change the list of spaces or rotate the API token. Removing a space drops its pages on the next refresh.
## Disconnecting
Click **Disconnect** on the Confluence detail page. Confluence stops being used within a few minutes, and citations to it stop appearing on new tickets.
## See also
* [Documentation](/dashboard/documentation) — how the agent uses all your connected documentation sources together
* [Hudu](/integrations/hudu) — per-client IT documentation, passwords, and procedures
* [IT Glue](/integrations/itglue) — per-client documentation, configurations, and passwords
# ConnectWise Manage
Source: https://docs.rallied.ai/integrations/connectwise
Have the agent live in ConnectWise Manage: pick up new tickets, post its work as notes, and run approvals in-thread without technicians switching tools.
Connect ConnectWise Manage so Rallied picks up new service tickets the moment they land, gathers the context your technicians would normally have to chase, and either resolves the ticket or hands it back with a clear plan.
ConnectWise Manage is configured in **Settings → Integrations**.
## Before you connect
Rallied signs in to ConnectWise using an API member you create. Rather than pointing that member at an existing role, give it a dedicated security role so its access is scoped to what Rallied actually needs, and nothing more.
### How permissions work
Think of it like onboarding a new team member: you give them a security role in ConnectWise so they **can** access the areas they need, then their manager decides which tasks they actually work on.
* **The ConnectWise security role** is the ceiling — the maximum API access Rallied **could** use.
* **Rallied's approval settings** are the actual controls — you decide which actions run automatically, which need a technician's approval, and which are disabled.
Granting access here doesn't mean Rallied will use everything. It means Rallied **can** operate when you enable a capability in your approval settings.
### Create the "Rallied" security role
In ConnectWise, go to **System → Security Roles** and create a new role called `Rallied`.
Configure the role with the permissions below.
**Read access — set Inquire Level to All (all entries) for these modules:**
| Security module | Inquire level | What it covers |
| - | - | - |
| Service Desk | All (all entries) | tickets, notes, boards, statuses, teams, SLAs, impacts, priorities, schedule entries |
| Companies | All (all entries) | companies, company types, contacts, configurations, teams |
| Time & Expense | All (all entries) | time entries logged against a ticket |
| Procurement | All (all entries) | products on a ticket |
| System | All (all entries) | members, attachments, webhook callbacks |
| Finance | All (all entries) | the agreement name attached to a ticket, so technicians see coverage context |
Reading is safe; it never changes anything in ConnectWise.
**Write access — set Add Level and Edit Level to All for these entries:**
| Entry | Add | Edit |
| - | - | - |
| Service Tickets | All | All |
| Close Service Tickets | All | All |
| Resource Scheduling | All | All |
| Entry | Add | Edit |
| - | - | - |
| Manage Attachments | All | All |
**Manage Attachments** is what lets Rallied attach files to tickets — for example, a screenshot a user shares in a chat. Without **Add: All** on this entry, attachments fail with a "You do not have security permission to perform this action" error.
| Entry | Add | Edit |
| - | - | - |
| Time Entry | All | All |
| Time Entry Billable Option | All | All |
| Entry | Add | Edit |
| - | - | - |
| Table Setup | All | All |
**Delete access — one entry only:**
| Module | Entry | Delete |
| - | - | - |
| System | Table Setup | All |
Rallied registers a webhook when you connect and removes it when you disconnect. Without delete access here, disconnecting leaves an orphaned callback firing at Rallied.
**Leave everything else read-only.** Keep Add, Edit, and Delete at **None** for anything not listed above — including Finance write entries (Invoicing, Agreements, Billing Rate Maintenance, Accounting Interface), Procurement write entries (Purchase Orders, Purchasing Approvals, Products), Project entries, Sales, Marketing, and the sensitive System entries (Member Maintenance, Security Roles, Add Licenses).
This is the least-privilege configuration for what Rallied writes today. If you want the agent working in a new area later, see [Granting more later](#granting-more-later) below.
### Granting more later
The role above covers what Rallied writes to today. Rallied also ships generic ConnectWise API tools (GET, POST, PATCH to any endpoint) that are disabled or approval-gated by default. If you want the agent working in areas this role doesn't cover (projects, agreements, purchase orders):
* Grant those entries in the ConnectWise security role.
* Enable the corresponding tools in your approval settings.
Start narrow; widen when you have a reason to.
## How to connect
In ConnectWise Manage, go to **System → Members → API Members** and create a new API member:
* **Security Role** — the `Rallied` role you created above.
* **Member ID** — a descriptive identifier like `rallied`.
* **Email** — an address you control.
Then, under that member, create a new **API key** pair. Note the **Public Key** and **Private Key** — the private key is shown only once.
ConnectWise doesn't let API-only members create time entries, and time has to be attributed to the technician who did the work. If your team will use the Rallied ticket workspace to log time or post customer-visible replies:
* Create a regular (non-API) member for each technician under **System → Members**.
* Map them in Rallied under **Settings → Integrations → ConnectWise → member mappings**.
Rallied still authenticates with the API member's keys. The mapped members are used only as the author of notes and time entries.
Unmapped users can still work in the ticket workspace — they just can't create time entries or customer-visible replies. Internal notes fall back to bot attribution with a generated author line.
In Rallied, go to **Settings → Integrations**.
Find the ConnectWise Manage card and click **Connect**. A credentials form appears.
Fill in:
* **ConnectWise URL** — your ConnectWise instance URL (e.g. `https://na.myconnectwise.net`)
* **Company ID** — your ConnectWise company identifier (the exact name from the ConnectWise login screen)
* **Public Key** — the public key from the API member
* **Private Key** — the private key from the API member
Click **Save**. Rallied validates the credentials, registers a webhook in ConnectWise, and imports your existing companies as clients. The card shows **Connected** when complete.
When you first connect ConnectWise, Rallied imports your ConnectWise companies as clients. New clients get an agent provisioned automatically.
## What happens when a ticket comes in
When a new service ticket is created in ConnectWise, Rallied picks it up right away. Your technician sees:
1. The ticket appears in ConnectWise as usual.
2. Within moments, Rallied posts an internal note with what the ticket is about, who it's from, and what it plans to do.
3. Anything Rallied can safely handle on its own (looking up context, drafting a response, running approved actions) happens without waiting.
4. Anything you've flagged for review shows up as an approval request on the ticket — approve or deny by replying to the note.
5. The technician approves the plan, denies it, or takes over. Rallied only acts on what you've cleared.
### If Rallied missed the ticket when it was created
ConnectWise only announces a new ticket once, and Rallied can skip that first announcement in a few cases:
* The ticket's company wasn't yet mapped to a Rallied client.
* The ticket's status wasn't one of the accepted statuses at creation time.
* ConnectWise was temporarily unreachable when Rallied went to fetch the ticket.
You don't have to do anything to recover. When a later note or update lands on the ticket and the client and status now qualify, Rallied starts the agent at that point. The agent picks the ticket up from its current state, including the note that triggered it.
### Sensitive tickets and identity verification
For sensitive tickets (password or MFA resets, for example), Rallied can verify the requester's identity before doing anything. If you've connected an identity provider like [Traceless](/integrations/traceless), Rallied sends the challenge and pauses until the requester approves, denies, or the request expires. The outcome is posted as an internal note so your team always sees what happened.
## Approving actions without leaving ConnectWise
When Rallied wants to take an action you've flagged for review, it posts an internal note on the ticket describing exactly what it plans to do. Reply to that note to approve or deny.
Rallied classifies the intent of the reply. A neutral reply (a status update, a comment for another tech) is ignored, so it won't accidentally approve or deny anything.
## Notes vs. customer-visible replies
The defaults are conservative. You can roll Rallied out without worrying about it messaging your customers in a tone you haven't approved:
* **Internal notes** — visible only to your technicians. This is what Rallied uses by default for its plans, updates, and reasoning.
* **Customer-visible replies** — visible to the end customer. Rallied only sends these when a workflow or instruction explicitly asks for one.
## Approval settings
Fine-tune what Rallied does automatically vs. what needs a technician's approval from **Settings → Integrations** (ConnectWise detail page). See [Approval settings](/dashboard/policies) for the full model.
## Related
* [Chat with your agent](/dashboard/chat) — embed the agent as a pod inside ConnectWise Manage.
* [Rallied API](/api/talk) — ask the agent about a ConnectWise ticket from your own automations, using the `connectwise_psa` slug.
* [Approval settings](/dashboard/policies) — the full approval model.
# ConnectWise Automate
Source: https://docs.rallied.ai/integrations/connectwise-automate
Have the agent act on ConnectWise Automate (LabTech) endpoints: run scripts, kick off remediations, and clear alerts from inside the originating ticket.
Connect ConnectWise Automate so the agent can list and inspect computers, look up clients and locations, run automation scripts on managed endpoints, and clear alerts after a fix.
ConnectWise Automate is configured in **Settings → Integrations**.
## How to connect
ConnectWise Automate uses **integrator credentials** issued from the Automate Control Center. Rallied exchanges them for an API access token on connect.
Open the Automate Control Center and go to **System → Integrator**. Create a new integrator account (or pick an existing one) and note the **username** and **password**. Make sure the integrator has the API permissions you want the agent to use: read-only for inventory and alerts, plus the relevant script-execution permissions if you plan to remediate.
In Rallied, go to **Settings → Integrations**.
Find the ConnectWise Automate card and click **Connect**. A credentials form appears.
Fill in:
* **Server Hostname** — your Automate server hostname, e.g. `automate.yourcompany.com` (no `https://` prefix or trailing slash; Rallied always uses HTTPS)
* **Integrator Username** — the integrator account's username
* **Integrator Password** — the integrator account's password
Click **Save**. Rallied posts to `https:///cwa/api/v1/apitoken` to obtain an access token, stores the credentials, and the card shows **Connected** when complete.
## How the agent uses it
When a request touches an Automate-managed endpoint (**"is DC01 online?"**, **"run our cleanup script on the kiosk"**, **"clear the noisy disk-space alert"**), the agent typically:
1. Resolves the client with `cwa-list-clients`, then finds the computer with `cwa-list-computers` (filter by client / hostname / OS) and pulls details from `cwa-get-computer`.
2. Triages alerts with `cwa-list-alerts` (tenant-wide) or `cwa-get-computer-alerts` (per device) to understand severity and context.
3. Picks a remediation script from `cwa-list-scripts` and schedules it on the target computer(s) with `cwa-run-script` (approval-gated).
4. Once the underlying issue is fixed, dismisses the alert with `cwa-clear-alert` (approval-gated).
## Tools
| Tool | Default policy | Description |
| - | - | - |
| `connectwise_automate:cwa-list-clients` | Auto | List clients in Automate |
| `connectwise_automate:cwa-list-computers` | Auto | List computers, optionally filtered by client, location, status, or OS |
| `connectwise_automate:cwa-get-computer` | Auto | Get full details for a specific computer |
| `connectwise_automate:cwa-list-alerts` | Auto | List alerts across the tenant |
| `connectwise_automate:cwa-get-computer-alerts` | Auto | List alerts for a specific computer |
| `connectwise_automate:cwa-clear-alert` | Approval needed | Clear (dismiss) an active alert |
| `connectwise_automate:cwa-list-scripts` | Auto | List automation scripts available in the tenant |
| `connectwise_automate:cwa-run-script` | Approval needed | Run a script on one or more computers |
## Policies
Per-tool policies are configured on the **ConnectWise Automate** integration detail page (open it from **Settings → Integrations**).
See [Approval settings](/dashboard/policies) for an overview.
# ConnectWise RMM
Source: https://docs.rallied.ai/integrations/connectwise-rmm
Have the agent act on ConnectWise RMM (Asio) endpoints: run scripts, remediate managed devices, and clear alerts from inside the originating ticket.
Connect ConnectWise RMM so the agent can look up devices, run automation scripts on managed endpoints, view patch status, and create or read service tickets across every client in your Asio tenant.
ConnectWise RMM is configured in **Settings → Integrations**.
## How to connect
ConnectWise RMM uses API credentials issued from the Asio platform. You'll generate them in the ConnectWise admin UI before starting.
In the Asio platform UI (`auplatform.connectwise.com`, `itsupport247.net`, or `euplatform.connectwise.com` depending on your region), go to **Integrations → API Access → Generate API Access**.
Select the scopes for the tools you want the agent to use:
| Area | Scopes |
| - | - |
| Companies and sites | Platform - Companies - Read, Platform - Sites - Read |
| Devices (list, details, state, services, heartbeat) | Platform - Devices - Read, Platform - DeviceGroups - Read, Platform - Agent - Read, Platform - Assets - Read |
| Device usage (CPU, memory, disk) | Platform - Performance - Read |
| Patches | Platform - Os Patching Endpoint Patches - Read |
| Scripts and tasks (list, run, read results) | Platform - Automation - Read, Platform - Automation - Create |
| RMM tickets | Platform - Tickets - Read. Add Platform - Tickets - Create to let the agent open RMM tickets. |
A missing scope doesn't block the connection. Instead, every tool that needs that scope fails with a "client has no access" error. If you connected before, add any missing scopes to your existing API Access in ConnectWise.
Automation - Create lets the agent run scripts on devices. Script runs still follow your approval policy. Copy the **Client ID** and **API Key** shown after generation. The API key is only displayed once.
In Rallied, go to **Settings → Integrations**.
Find the ConnectWise RMM card and click **Connect**. A credentials form appears.
Fill in:
* **Client ID** — the Client ID from the Asio API Access page
* **Client Secret** — the API key generated alongside the Client ID
* **Region** — `au` (default), `na`, or `eu`, matching your ConnectWise instance
Click **Save**. Rallied authenticates against the Asio OAuth2 endpoint, stores the access token, and the card shows **Connected** when complete.
After connecting, Rallied automatically discovers every **active shell script** in your ConnectWise RMM tenant and registers each one as a per-script tool. Each script gets its own policy you can tune (auto, approval-needed, never) from the integration detail page.
## How the agent uses it
When a user asks about a server, workstation, or company managed in ConnectWise RMM (**"is DC01 healthy?"** or **"run the disk cleanup script on Maria's laptop"**), the agent:
1. Resolves the device by name using `cw-rmm-list-devices` (optionally scoped to the company).
2. Pulls health, patch status, or system state with `cw-rmm-get-device`, `cw-rmm-get-device-state`, or `cw-rmm-get-device-patches`.
3. Inspects services or resource pressure with `cw-rmm-list-endpoint-services` and `cw-rmm-get-endpoint-usage`, and checks reachability with `cw-rmm-get-endpoint-heartbeat` before and after taking action.
4. If remediation is needed, picks from three options:
* **An existing shell script** already in your ConnectWise RMM tenant and schedules it via the dedicated per-script tool (e.g. `cw-rmm-script-disk-cleanup`).
* **A new inline script** written for the task using one of the generic runner templates (PowerShell, Bash, or Command Prompt) via `cw-rmm-run-task`.
* Script runs go through your configured [approval policy](/dashboard/policies). In a [workflow](/dashboard/workflows), they can be set to auto-run if pre-approved.
5. When a script run requires approval, the technician sees a **script analysis** showing the proposed script content before deciding. See [Execute mode](/agents/execute-mode) for how approval and script analysis work.
The agent also reads and creates tickets in the same RMM tenant so it can leave a paper trail alongside automation runs.
Device and task tools call the Asio **v2** API. Unlike v1, v2 returns device names directly, so the agent doesn't have to cross-reference IDs to work out which machine a response refers to.
## Tools
### Static tools
| Tool | Default policy | Description |
| - | - | - |
| `connectwise_rmm:cw-rmm-list-companies` | Auto | List all companies (clients) in ConnectWise RMM |
| `connectwise_rmm:cw-rmm-get-company` | Auto | Get details for a specific company |
| `connectwise_rmm:cw-rmm-list-sites` | Auto | List sites across the partner or for one company |
| `connectwise_rmm:cw-rmm-list-devices` | Auto | List managed endpoints, optionally filtered by company or site |
| `connectwise_rmm:cw-rmm-get-device` | Auto | Get hardware, OS, and network details for an endpoint |
| `connectwise_rmm:cw-rmm-get-device-state` | Auto | Get live CPU, memory, disk, and process state for an endpoint |
| `connectwise_rmm:cw-rmm-get-device-patches` | Auto | List pending, installed, and failed patches for an endpoint |
| `connectwise_rmm:cw-rmm-get-endpoint-heartbeat` | Auto | Check online/offline status and last-seen timestamp for every device in a company |
| `connectwise_rmm:cw-rmm-list-endpoint-services` | Auto | List system services on a device with status and startup type, optionally filtered by service name |
| `connectwise_rmm:cw-rmm-get-endpoint-usage` | Auto | Get the latest CPU, memory, and disk usage for a device |
| `connectwise_rmm:cw-rmm-list-device-groups` | Auto | List configured device groups |
| `connectwise_rmm:cw-rmm-list-scripts` | Auto | List all automation scripts available in the tenant |
| `connectwise_rmm:cw-rmm-list-shell-scripts` | Auto | List shell scripts (PowerShell, Bash, etc.) |
| `connectwise_rmm:cw-rmm-list-tasks` | Auto | List automation tasks |
| `connectwise_rmm:cw-rmm-get-tasks-summary` | Auto | Get a summary of tasks across the tenant or for one endpoint. Returns `upstreamUnavailable: true` if ConnectWise doesn't respond within 25 seconds — the task-summary endpoint has no pagination and can stall on devices with a very large task history |
| `connectwise_rmm:cw-rmm-run-task` | Approval needed | Schedule an inline script on one or more endpoints using one of the generic runner templates (PowerShell, Bash, or Command Prompt). When a dedicated `cw-rmm-script-*` tool exists for the script, the agent uses that instead |
| `connectwise_rmm:cw-rmm-get-task-results` | Auto | Get execution results for a task instance |
| `connectwise_rmm:cw-rmm-list-tickets` | Auto | List service tickets |
| `connectwise_rmm:cw-rmm-get-ticket` | Auto | Get full details of a specific ticket |
| `connectwise_rmm:cw-rmm-create-ticket` | Approval needed | Create a new service ticket |
### Dynamic script tools
Every active shell script in your ConnectWise RMM tenant is also registered as its own tool named `cw-rmm-script-`. Each one accepts the script's published parameters plus a list of target endpoint UUIDs (or a company ID if you set `targetType: COMPANY`).
The agent's policy classifier picks a default policy per script based on its name and description. You can override it from the **ConnectWise RMM** integration detail page.
## Policies
Per-tool and per-script policies are configured on the **ConnectWise RMM** integration detail page (open it from **Settings → Integrations**).
See [Approval settings](/dashboard/policies) for an overview.
# Datto RMM
Source: https://docs.rallied.ai/integrations/datto-rmm
Have the agent triage Datto RMM alerts and run quick jobs against managed endpoints without a technician ever needing to open the Datto console.
Connect Datto RMM so the agent can list and inspect devices, audit hardware / software / network, triage and resolve alerts, and run quick jobs across every site in your Datto RMM tenant.
Datto RMM is configured in **Settings → Integrations**.
## How to connect
Datto RMM uses a tenant-specific API endpoint plus a single API key. You generate both in the Datto RMM web UI before connecting.
Sign in to your Datto RMM tenant as an administrator. Open **Setup → Users** (or your tenant's API page) and create / enable an API user. Grant the permissions you want the agent to use: Devices, Alerts, Sites, and Jobs at minimum. Copy:
* The **API URL** for your region (e.g. `https://pinotage-api.centrastage.net` or your platform-specific equivalent)
* The **API Key** issued for the API user
In Rallied, go to **Settings → Integrations**.
Find the Datto RMM card and click **Connect**. Enter:
* **API URL** (`base_url`) — your region-specific Datto RMM API endpoint
* **API Key** — the API key issued for the API user
Rallied stores the credentials and uses the `x-au-api-key` header on every call.
The agent currently uses the v1 Datto RMM API directly with the stored API key. There is no OAuth dance, so the connection stays active as long as the API key is valid. If you rotate the key in Datto RMM, open the Datto RMM detail page, click **Update connection**, and enter the new key. See [updating an integration's credentials](/dashboard/integrations#updating-an-integrations-credentials).
## How the agent uses it
When a request touches a Datto-managed endpoint or alert (**"why did the disk-space alert fire on FILE01?"**, **"run our reboot quick job on the lobby kiosk"**), the agent typically:
1. Finds the alert with `datto-list-alerts` (optionally scoped to a site), or jumps straight to the device with `datto-list-devices` / `datto-get-device`.
2. Resolves site context with `datto-list-sites` / `datto-get-site` when the request is "all of Acme's servers" style.
3. Digs deeper with `datto-get-device-audit` using `type: "software"`, `"hardware"`, or `"network"` to understand the underlying cause.
4. Runs a remediation with `datto-run-quickjob` (approval-gated). The `jobName` must match a component already configured in Datto RMM for that device's site.
5. Once the root cause is addressed, dismisses the alert with `datto-resolve-alert` (approval-gated).
Resolving an alert in Datto RMM **does not fix the underlying issue**, so the agent is instructed to address the root cause first and only then resolve the alert as bookkeeping.
## Tools
| Tool | Default policy | Description |
| - | - | - |
| `datto_rmm:datto-list-sites` | Auto | List sites (customer environments) in Datto RMM |
| `datto_rmm:datto-get-site` | Auto | Get details for a specific site |
| `datto_rmm:datto-list-devices` | Auto | List managed devices, optionally filtered by site |
| `datto_rmm:datto-get-device` | Auto | Get full details for a specific device |
| `datto_rmm:datto-get-device-audit` | Auto | Audit a device's `software`, `hardware`, or `network` (or all three) |
| `datto_rmm:datto-list-alerts` | Auto | List open alerts, optionally scoped to a site |
| `datto_rmm:datto-resolve-alert` | Approval needed | Resolve (dismiss) an alert by UID |
| `datto_rmm:datto-run-quickjob` | Approval needed | Run a quick job (named component) on a target device, with optional key-value variables |
## Policies
Per-tool policies are configured on the **Datto RMM** integration detail page (open it from **Settings → Integrations**).
See [Approval settings](/dashboard/policies) for an overview.
# HaloPSA
Source: https://docs.rallied.ai/integrations/halopsa
Have the agent work HaloPSA tickets end-to-end: pick up new requests, post actions and internal notes, and import your HaloPSA clients in one shot.
## Overview
The HaloPSA integration is a three-part setup that runs in parallel between the **HaloPSA admin UI** and **Rallied**. Keep both tabs open while you work through it.
1. **In HaloPSA** — create a dedicated API agent, register an Application against that agent, and copy the Client ID + Client Secret.
2. **In Rallied** — open the HaloPSA integration form, paste the credentials, and save.
3. **In Rallied (post-connect)** — select which HaloPSA clients to import as Rallied clients. Each imported client is provisioned with an agent automatically.
The whole flow takes about 10 minutes.
## Section 1 — Create the API agent in HaloPSA
Use an account with **Administrator** rights.
Go to **Configuration → Teams & Agents → Agents** and click **New**.
Fill in the following (leave other fields at their defaults):
| Field | Value |
| - | - |
| Username | `Rallied Agent` |
| Password | *leave blank* |
| Use AD authentication | No |
| Roles | Administrator |
| Is an API-only Agent | **Yes** |
| First Name | `Rallied` |
| Surname | `Agent` |
| Initials | `RA` |
| Default Team | *No Default Team* |
| Work Hours | 24 Hours |
Click **Save**.
![Image]()
## Section 2 — Register the Application
The Application is what Rallied uses to call the HaloPSA API.
Go to **Configuration → Integrations → HaloPSA API → Applications → View Applications** and click **New**.
Fill in:
| Field | Value |
| - | - |
| Application Name | `Rallied Agent` |
| Authentication Method | **Client ID and Secret (Services)** |
| Login Type | **Agent** |
| Agent to log in as | `Rallied Agent` (the agent from Section 1) |
HaloPSA generates a **Client ID** and **Client Secret**. Copy both; you'll paste them into Rallied in Section 3. The secret is only displayed once.
![591441961 C6e1d6b1 Cc37 49e2 Adef 72dd9b170ccf]()
On the **Permissions** tab, enable the three scopes Rallied needs:
| Permission | Purpose |
| - | - |
| `all:standard` | Read/write tickets, notes, customers, assets, and users |
| `all:teams` | Access to all Teams regardless of the agent's own team membership |
| `admin:webhooks` | Lets Rallied register and refresh its own webhook automatically |
Leave `all` and `admin` **unchecked** — `all:standard` plus `admin:webhooks` is the least-privileged set that lets the integration work.
![591442127 E5e2572e 388c 468d 831f 3695102af08d]()
Click **Save**. Leave the page open — you still need the Client ID and Client Secret in the next section.
## Section 3 — Connect HaloPSA in Rallied
In Rallied, go to **Settings → Integrations**.
Find the HaloPSA card and click **Connect**. A credentials form appears.
Fill in:
* **Instance URL** — your HaloPSA tenant URL, e.g. `https://yourcompany.halopsa.com` (no trailing slash; HTTPS required)
* **Client ID** — from the Application in Section 2
* **Client Secret** — from the Application in Section 2
Click **Save**. Rallied validates the connection. If the credentials are wrong, you'll see an inline error; re-check the values and re-save.
![591442030 7d3124c8 18bf 4f1a 8934 D8e3f9bc7297]()
After saving, the **Select clients to import** post-connect step opens. Pick which HaloPSA clients you want to manage with Rallied. Each one is imported with an agent provisioned automatically.
Rallied registers the webhook in HaloPSA for you and subscribes it to new and updated ticket events. You don't need to add the webhook or notifications manually.
## What happens when a ticket comes in
When a new or updated ticket lands in HaloPSA, the agent picks it up right away, matches it to the right client, and starts working with the full ticket context: subject, requester, priority, prior notes, and attached files.
### Attachments
The agent can read ticket attachments including files stored in S3-linked storage. It lists attached files, reads their contents when relevant (plain text, PDF with a text layer, Word documents, and email messages), and uses the information to diagnose the issue. The agent never pastes a signed storage link as text.
If you've set up [workflows](/dashboard/workflows) that match the incoming ticket, the agent follows your instructions for that scenario.
### Sensitive tickets and identity verification
If a ticket is classified as sensitive (a password or MFA reset, for example) and you have a verification provider like [Traceless](/integrations/traceless) connected, Rallied sends the requester an identity verification challenge before the agent starts work. The agent pauses until the verification resolves, then posts an internal note on the ticket with the outcome.
## Approving an action without leaving HaloPSA
When the agent's plan needs a technician's sign-off, it creates a HaloPSA action on the ticket describing what it wants to do. Your team approves or denies from HaloPSA.
Only the ticket's assigned agent can approve. Replies from anyone else are treated as normal messages and don't affect the approval.
## Replying to the agent on a ticket
Once the agent has started working a ticket, any new note on that ticket is forwarded to it as a follow-up in the same session. That covers both **internal notes** from your technicians and **customer replies** from end users, so a tech can drop a hint mid-investigation, an end user can answer the agent's clarifying question, and the agent picks up where it left off — no re-triggering needed.
Each forwarded note is labeled with its source (internal note or customer reply), so the agent always knows who it's talking to.
Two things are never forwarded:
* **The agent's own notes.** Only notes from an identified human author reach the agent, so it never reacts to itself.
* **Replies on tickets the agent never worked.** Commenting on an old ticket won't silently wake an agent.
## Testing the end-to-end setup
Click **New Ticket** at the top of any HaloPSA page. Pick any ticket type, assign it to an imported client, and fill in a short subject and description.
Go to **Configuration → Integrations → Webhooks**, open the `Rallied (...)` webhook, and check the **Deliveries** tab. You should see a successful delivery for the new ticket.
In Rallied, open **Activity** (or the imported client's detail page). The new ticket should appear with the agent's diagnosis already in progress. If the operating mode is **Plan**, the agent posts an internal note with its plan; in **Execute** mode it begins executing read-only steps and requests approval for write actions.
If the ticket doesn't appear in Rallied, double-check:
* The Instance URL has no trailing slash and uses HTTPS
* The Client Secret hasn't been regenerated since you saved it in Rallied
* The client linked to the test ticket was imported in Section 3
## Policies
You can adjust HaloPSA tool policies from **Settings → Integrations** (open the HaloPSA detail page).
# Hudu
Source: https://docs.rallied.ai/integrations/hudu
Let the agent answer client questions the way your senior technicians would: it reads Hudu articles, passwords, and assets, and cites the exact source.
Connect Hudu and every client agent works from your existing IT documentation (companies, assets, articles, procedures, Central KB, and passwords) the same way a senior technician would. Every internal note the agent posts on a ticket links back to the exact Hudu record behind each claim.
Hudu is configured in **Settings → Integrations**.
## What it's for
Hudu is where most MSPs keep their per-client documentation — asset records, network diagrams, service accounts, "how we do X for client Y." Connect it and the whole library is on hand for every ticket, scoped to the client the ticket belongs to.
## How to connect
Hudu uses API key authentication.
Sign in to Hudu as an admin and go to **Admin → API Keys**. Click **+ Add new API Key**, give it a recognizable name (e.g. `Rallied Integration`), and copy the key. It's shown only once.
In Rallied, go to **Settings → Integrations**.
Find the Hudu card and click **Connect**. A credentials form appears.
Fill in:
* **API Key** — the key you generated above.
* **Hudu URL** — your Hudu hostname (e.g. `yourdomain.huducloud.com` for Hudu Cloud, or `hudu.yourmsp.com` for self-hosted). You can paste the full URL with `https://`; Rallied handles the rest.
Self-hosted Hudu must be reachable from the public internet over HTTPS with a valid, publicly-trusted TLS certificate.
Click **Save**. Rallied validates the key against your Hudu instance and imports your companies as candidate client mappings. The card shows **Connected** when it's ready.
## Mapping companies to clients
Hudu stores documentation per **company**. On each Rallied client's detail page, pick the matching Hudu company. From then on, every Hudu lookup the agent does for that client stays scoped to that company, so there's no risk of pulling another client's runbook into a response.
If a client isn't mapped to a Hudu company, the agent will not use Hudu for that client's tickets.
The **Internal** company in Hudu (the one representing the MSP itself) is excluded from client mapping. Central KB articles and shared procedures are still available to every client agent as MSP-wide knowledge.
## What your technicians see
Every internal note the agent posts on a ticket includes clickable links back to the exact Hudu record it used: the specific article, procedure, or asset. Technicians open the note, see the plan, and click straight through to the source. Outdated runbooks get spotted (and fixed) as a byproduct of working tickets.
## What the agent reads
| Type | Typical content |
| - | - |
| **Companies** | Client records, contact info, top-level overview |
| **Assets** | Servers, devices, software, custom asset layouts your team has defined |
| **Articles** | Knowledge base articles, runbooks, "how we do X for client Y" |
| **Procedures** | Documented step-by-step procedures and SOPs (called **Procedures** in Hudu) |
| **Central KB** | Articles that aren't tied to a specific company — your MSP's shared playbooks |
| **Passwords** | Service accounts, admin credentials, shared logins |
PDF attachments on Hudu articles are used the same as the article text, so vendor guides and RFPs your team keeps attached are searchable too.
## Passwords and approval
Passwords retrieved from Hudu are sensitive. The `hudu-get-password` tool reveals the value, so the agent records in its notes why a credential was accessed. For especially sensitive operations, you can tighten this further:
* Require [identity verification](/agents/identity-verification) before the agent uses any retrieved credential.
* Change the tool's setting from **Auto-approve** to **Needs approval** on **Settings → Integrations → Hudu**.
Passwords are searchable by name only, never by value, so the agent can identify that a credential exists without seeing it until it explicitly retrieves it.
## Managing your Hudu documentation
Open **Settings → Integrations → Hudu** to see:
* How much of your Hudu content is available to the agent
* How often the agent has cited a Hudu record in the last 30 days
* When Hudu was last refreshed
* A **Sync now** button to pull in the latest edits immediately
See [Documentation](/dashboard/documentation) for the full picture of how the agent uses all your connected documentation together.
## Approval settings
Read actions default to **Auto-approve** so the agent can consult your documentation freely during diagnosis. Write actions — like creating a new knowledge base article — default to **Needs approval**.
Fine-tune from **Settings → Integrations → Hudu**. Per-client overrides live on the client's detail page.
## See also
* [Documentation](/dashboard/documentation)
* [IT Glue](/integrations/itglue)
* [Confluence](/integrations/confluence)
# IT Glue
Source: https://docs.rallied.ai/integrations/itglue
Ground the agent in your IT Glue: it reads documents, passwords, configurations, and flexible assets on every ticket and cites the source page it used.
Connect IT Glue and every client agent works from your existing documentation: runbooks, configurations, passwords, and flexible assets. On every ticket, the internal note the agent posts links back to the exact IT Glue record for each claim it makes.
IT Glue is configured in **Settings → Integrations**.
## What it's for
IT Glue is where a lot of MSPs keep their per-client documentation. Connect it and the whole library is on hand for every ticket, scoped to the client the ticket belongs to.
## How to connect
IT Glue uses API key authentication.
In IT Glue, go to **Account → Settings → API Keys** and click **Generate a new API key**. Give it a recognizable name (e.g. `Rallied Integration`) and copy the key. It's shown only once.
Use a key with **read-only** access if you only want the agent consulting documentation. Use a key with **write** access if you want the agent creating or updating documents and flexible assets through the approval flow.
In Rallied, go to **Settings → Integrations**.
Find the IT Glue card and click **Connect**. A credentials form appears.
Fill in:
* **API Key** — the key you generated above.
* **Region** — your IT Glue region: **US**, **EU**, or **AU**.
Click **Save**. Rallied validates the key and imports your organizations as candidate client mappings. The card shows **Connected** when it's ready.
## Mapping organizations to clients
IT Glue stores documentation per **organization**. On each Rallied client's detail page, pick the matching IT Glue organization. From then on, every IT Glue lookup the agent does for that client stays scoped to that organization, so it can't pull another client's runbook into a response.
If a client isn't mapped to an IT Glue organization, the agent will not use IT Glue for that client's tickets.
## What your technicians see
Every internal note the agent posts on a ticket includes clickable links back to the exact IT Glue record it used. Technicians open the note, see the plan, and click straight through to the source. There's no guessing where a fact came from, and outdated documentation gets spotted and fixed as a byproduct of working tickets.
## What the agent reads
| Type | Typical content |
| - | - |
| **Documents** | Runbooks, procedures, "how we do X for client Y" |
| **Configurations** | Servers, network devices, endpoints, software versions |
| **Passwords** | Service accounts, admin credentials, shared logins |
| **Flexible assets** | Custom asset types your team has defined (SSL certs, Office 365 tenants, vendor records, etc.) |
| **Contacts** | Client-side stakeholders, escalation paths |
## Passwords and approval
Passwords retrieved from IT Glue are sensitive. The `get-password` action defaults to **Needs approval**. The agent can identify **that** a password is needed for a step, but can't reveal or use it until a technician approves. You can change this in **Settings → Integrations → IT Glue**.
For especially sensitive operations, you can also require [identity verification](/agents/identity-verification) before the agent uses any retrieved credential.
Passwords are searchable by name only, never by value, so the agent can tell that a credential exists without seeing it until it explicitly retrieves it.
## Managing your IT Glue documentation
Open **Settings → Integrations → IT Glue** to see:
* How much of your IT Glue content is available to the agent
* How often the agent has cited an IT Glue record in the last 30 days
* When IT Glue was last refreshed
* A **Sync now** button to pull in the latest edits immediately
See [Documentation](/dashboard/documentation) for the full picture of how the agent uses all your connected documentation together.
## Approval settings
Read actions default to **Auto-approve** so the agent can consult documentation freely during diagnosis. Write actions and password retrieval default to **Needs approval**.
Fine-tune from **Settings → Integrations → IT Glue**. Per-client overrides live on the client's detail page.
## See also
* [Documentation](/dashboard/documentation)
* [Hudu](/integrations/hudu)
* [Confluence](/integrations/confluence)
# Jira
Source: https://docs.rallied.ai/integrations/jira
Put the agent to work on Atlassian Jira: pick up issues, post internal comments, run approvals, and use Jira Assets as its source of truth for CMDB data.
Connect Jira Service Management and Rallied's agents pick up new issues the moment they land, with no polling or manual trigger. The agent reads and updates issues, posts comments, and manages Jira Assets objects, so routine service-desk work moves without a technician touching it.
Jira is configured from **Settings → Integrations**.
## How to connect
Navigate to **Settings → Integrations**.
Find the Jira card and click **Connect**. An Atlassian authorization window opens.
Sign in to Atlassian and grant Rallied access to your Jira instance in the sign-in window that opens.
After authorizing, Rallied prompts you to select the Jira project to monitor. This tells Rallied which project's new issues should wake the agent.
The Jira card shows **Connected**. Incoming tickets from the selected project will now trigger the agent automatically.
## What happens when an issue comes in
When a new issue is created in the connected Jira project, the agent picks it up right away and starts working with the full issue context: summary, description, reporter, and priority.
If you've set up [workflows](/dashboard/workflows) that match the issue, the agent follows your instructions for that scenario.
## Approving an action without leaving Jira
When the agent's plan needs a technician's sign-off, it posts a comment on the Jira issue describing what it wants to do. Your team approves or denies from Jira, with no separate tool to check.
If you also have Slack connected for the same client, the agent sends a Slack DM to the technician in addition to the Jira comment. Technicians can approve from either channel — whichever they see first.
When a technician approves or denies via Slack, a note is automatically posted back on the Jira issue recording who resolved it and when.
## What the agent can do in Jira
**Runs automatically**
* Read any issue and pull its summary, status, assignee, and description.
* Post internal comments (only your service-desk team sees them). The agent uses these for its reasoning and status updates.
* Post public comments to the reporter or customer when it needs to reply.
* Search and read Jira Assets: look up objects, check attributes, list schemas and object types.
**Needs approval**
* Create a new Assets object.
* Update attributes on an existing Assets object.
* Delete an Assets object.
Deleting an Assets object is irreversible. Delete always needs approval and can't be flipped to auto. Confirm this fits your client before rolling it out.
## Approval settings
See [Approval settings](/dashboard/policies) for an overview. Per-tool settings live on the Jira detail page (open it from **Settings → Integrations**).
# MCP servers
Source: https://docs.rallied.ai/integrations/mcp-servers
Teach the agent new tricks: point Rallied at a remote Model Context Protocol (MCP) server and its actions become tools your helpdesk agent can call.
MCP (Model Context Protocol) servers let you connect tools that aren't available as built-in integrations. Any server that implements the Model Context Protocol can be connected to Rallied. The agent discovers the tools it exposes automatically and uses them the same way it uses any other tool.
Common use cases include:
* Internal APIs and custom business systems
* Proprietary tools specific to your MSP
* Third-party services not yet in the built-in integration catalog
## How to connect an MCP server
Navigate to **Settings → Integrations**.
Click the **Add MCP Server** button in the top-right corner of the page.
Paste the full URL of your MCP server endpoint (e.g. `https://tools.yourcompany.com/mcp`).
Rallied probes the server to detect what authentication it requires:
If the server uses OAuth, you are redirected to an authorization flow. Complete the authorization in your browser. The token is stored securely and passed to the server at runtime.
If the server uses Bearer token authentication, a field appears asking for your token. Enter it and click **Save**. The token is stored securely.
If the server requires no authentication, the connection completes immediately after the probe succeeds.
Rallied fetches the tool list from your MCP server and adds all discovered tools to the agent's catalog. Default policies are seeded automatically based on each tool's name and description. The server shows as connected and the agent can start using the tools immediately.
## Authentication types
| Type | How it works |
| - | - |
| **OAuth (PKCE)** | Rallied initiates an OAuth PKCE authorization flow. You complete the login in your browser. The token is refreshed automatically. |
| **Bearer token** | You provide a static token. It is stored securely and sent in the `Authorization: Bearer` header on every request. |
| **None** | No authentication is required. The server accepts requests directly. |
## Managing tools from MCP servers
Tools from custom MCP servers appear in the agent's tool catalog alongside built-in integration tools. You manage their policies the same way:
* Open the MCP server's detail page from **Settings → Integrations**
* Find the tool by name (MCP tools are prefixed with `mcp::`)
* Set the permission to **Auto**, **Approval needed**, or **Disabled**
| Tool looks like | Seeded default |
| - | - |
| Read operations (`get`, `list`, `search`, `fetch`) | **Auto** |
| Write operations (`create`, `update`, `delete`, `send`) | **Approval needed** |
You can override any of these defaults.
## Managing multiple MCP servers
You can connect multiple MCP servers. Each server's tools appear in the catalog independently. If two servers expose a tool with the same name, the agent uses them as separate tools distinguished by their server prefix.
To disconnect an MCP server, open **Settings → Integrations**, find the server in the list, and click **Disconnect**. This removes the server's tools from the agent's catalog and deletes the associated policies.
# Microsoft 365
Source: https://docs.rallied.ai/integrations/microsoft-365
Close identity, mailbox, and Teams tickets across every customer tenant: the agent handles user lookups, password resets, and group changes end-to-end.
## Overview
The Microsoft 365 integration uses a **multi-tenant app registration** in your MSP's partner tenant to manage customer tenants via GDAP. Once connected, the agent can:
* **Manage user lifecycle** — create, disable, and enable users; assign and remove licenses; reset passwords.
* **Manage groups and distribution lists** — add and remove members from both security groups and mail-enabled distribution lists.
* **Manage Exchange mailboxes** — grant shared mailbox access, convert to shared mailbox, forward email.
* **Respond to security incidents** — revoke active sign-in sessions for a user, look up sign-in failures, and check risky-user status.
* **Contain email compromise** — stop mailbox-level forwarding, and list and remove Outlook inbox rules. See [Email forwarding and inbox rules](#email-forwarding-and-inbox-rules).
* **Send email on behalf of a mailbox** — for out-of-band notifications during an incident (e.g. notifying a manager that a compromised account has been contained).
* **Manage SharePoint and OneDrive files** — browse libraries, find files, restore deleted items, and grant or remove access to a folder, file, library, or site. See [SharePoint and OneDrive](#sharepoint-and-onedrive).
* **Find shared mailboxes that still hold a license** — sweep every customer tenant for licenses you can likely reclaim. See [Licensed shared mailboxes](#licensed-shared-mailboxes).
* **Trace email delivery** — find out whether a message arrived, was quarantined, or was marked as spam, and where it really came from. See [Message trace](#message-trace).
* **Read Conditional Access policies** — explain why a user is asked for MFA or blocked, and audit which policies exclude whom. See [Conditional Access policies](#conditional-access-policies).
All operations respect your configured tool policies. Write operations (password reset, user creation, group changes) require approval by default.
**Already running CIPP?** Connect the [CIPP integration](/integrations/cipp) and Phase 3 is hands-off: Rallied pushes admin consent into every customer tenant on its own (when you connect CIPP, and again on every Sync), and picks up Exchange tools (distribution groups, shared mailboxes) and SharePoint site-permission reads through CIPP without assigning the Exchange Administrator role in each tenant.
***
## Phase 1: Configure the MSP's partner tenant
These steps are performed once in the MSP's own Entra tenant.
### 1. Create an app registration
1. Sign in to [**entra.microsoft.com**](https://entra.microsoft.com) with your partner tenant admin account
2. Navigate to **Applications → App registrations → + New registration**
3. Fill in:
* **Name** — e.g. `Rallied Integration` (this display name appears in role pickers across all customer tenants — make it recognizable)
* **Supported account types** — select **"Accounts in any organizational directory (Multitenant)"**
* **Redirect URI** — add one: type **Web**, any URL you control (e.g. your Rallied dashboard URL). It isn't used at runtime, but Phase 3's admin-consent step needs one registered.
4. Click **Register**
Save the **Application (client) ID** and **Directory (tenant) ID** from the Overview page — you'll need both when connecting in Rallied.
### 2. Generate a client secret
1. In the app registration, go to **Certificates & secrets → + New client secret**
2. Set a description (e.g. `Rallied production`) and expiration (24 months recommended)
3. Click **Add**
Copy the secret **Value** immediately — it disappears after you navigate away from this page.
### 3. Add the API permission
Navigate to **API permissions → + Add a permission → Microsoft Graph → Application permissions** and add **`Directory.Read.All`**. Rallied uses it to list your customer tenants from your partner tenant; it is the only permission connecting needs.
Azure lists **Delegated permissions** and **Application permissions** as two separate tabs with the same permission names under each. Make sure you're adding this under **Application permissions**.
Everything else is granted **per customer tenant, after you connect**, by Rallied itself: through CIPP if you connect it, or — if you approve tenants yourself — once the two setup permissions from Phase 3, Step 2 are on the app and a tenant has approved consent. The full list is in [Permissions Rallied requires](#permissions-rallied-requires).
### 4. Grant admin consent
Still on the **API permissions** page:
1. Click **Grant admin consent for \[your organization]** at the top
2. Confirm in the dialog
3. Verify the **Status** column shows a green checkmark ("Granted") next to `Directory.Read.All`
Granting consent requires **Global Administrator** or **Privileged Role Administrator** in the partner tenant. Cloud Application Administrator is not sufficient for Microsoft Graph application permissions.
***
## Phase 2: Connect in Rallied
1. In Rallied, go to **Settings → Integrations → Microsoft 365**
2. Click **Connect**
3. Enter:
* **Application (Client) ID** — from Phase 1, Step 1
* **Client Secret** — from Phase 1, Step 2
* **Partner Tenant ID** — from Phase 1, Step 1
4. Click **Submit**
Rallied validates credentials by acquiring an app-only token from Microsoft Entra ID. If successful, the integration appears as connected.
***
## Phase 3: Onboard customer tenants
Right after you connect, Rallied opens a short guided setup on the **Companies** tab: two steps, then a pointer at the one thing left to do in the table. On a fresh connection the setup runs through to the end. If you come back to it later from the **Continue setup** banner at the top of the page, you can leave with **Exit setup**.
![M365 Companies Tab]()
### Step 1: Sync tenants
This starts on its own the moment you connect: Rallied pulls every customer tenant your partner tenant has delegated access to and lists them in the table, each with a **Status**. New tenants start as **Not yet consented**. The step shows the sync running and continues by itself once at least one tenant is in. If Microsoft returns none, there is nothing to set up yet — add the partner relationships in Partner Center and click **Sync again**. Later, **Sync from Microsoft** on the Companies tab picks up new tenants.
### Step 2: Choose how Rallied gets access
Pick one of the two options in the guide. You only do this once per MSP.
If your MSP already runs CIPP, click **Connect CIPP** and enter its credentials (details on the [CIPP page](/integrations/cipp)). From then on there is nothing to do per tenant: Rallied pushes admin consent into every tenant through CIPP — right away for the tenants already in the table, and on every later Sync for new ones. Rows show **Processing…** while the consent lands, then **Ready**.
If you don't run CIPP, click **Approve yourself**. The guide shows the two Application permissions to add to the app registration you connected Rallied with (`Application.ReadWrite.All` and `AppRoleAssignment.ReadWrite.All`, Microsoft Graph) with a button that opens Azure Portal, and grant admin consent for them in your partner tenant. Add them once, then for each tenant marked **Not yet consented**:
1. Click **Grant admin consent** on that row
2. Sign in as a Global Administrator (or Privileged Role Administrator) of the customer tenant — or via GDAP if your relationship includes those roles — and approve
That's the only per-tenant click. The consent page grants what the app declares (those two permissions plus `Directory.Read.All` from Phase 1); with them in the tenant, Rallied grants itself every other permission in the [permissions list](#permissions-rallied-requires) and assigns the Exchange Administrator and User Administrator roles. The row turns **Processing…**, then **Finishing setup…** while Microsoft propagates the new grants, then **Ready**.
**Changing the method later.** On the Companies tab, the line under the description reads *Access method: Through CIPP* or *You approve each tenant*, with **Change**. It opens the same two cards. To move to CIPP, pick it and connect CIPP there. To move away from CIPP, pick *Approve yourself* and use **Manage CIPP** to disconnect it first, then add the two permissions.
**With CIPP, directory roles are not part of a tenant's status**: mailboxes and groups go through CIPP's own endpoints. Password resets, user enable/disable and user deletion still try Microsoft Graph first with the Rallied app; if Microsoft refuses with a 403 because the app holds no role that allows them (see [which roles count](#which-roles-count)), Rallied retries the change through CIPP, which acts under your GDAP roles. A **Ready** tenant under CIPP carries no note about roles: there is nothing for you to do about them.
Cloud Application Administrator and Application Administrator are **not sufficient** to approve consent — Microsoft restricts consent for Graph application permissions to Global Administrator or Privileged Role Administrator ([source](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/user-admin-consent-overview)).
### Step 3: Approve your tenants
When the two steps are done, the setup points at the first tenant's **Grant admin consent** button in the table — that is the whole per-tenant job, one click each. The header counts how many are ready and how many have an update available (`12 companies · 8 ready · 3 with an update available`). The **Status** column tells you where each tenant is and whether anyone has to do anything; hover a status for the detail (the exact permission or directory role it is waiting on), and open **Details** on the row for the rest: **Permissions** (what Rallied's app holds in that tenant, read from Microsoft Graph at that moment — every application permission, and the directory roles held directly or through a group), **History** (every consent, permission and role Rallied pushed, granted or found there — who, when, how it went), and when the tenant was last checked.
| Status | Meaning | What to do |
| - | - | - |
| **Not yet consented** | The tenant hasn't approved Rallied's app | With CIPP: nothing, it's pushed on the next check; if CIPP accepted the request and nothing landed, the tooltip says when Rallied asked and points at CIPP's logbook. Without CIPP: click **Grant admin consent** |
| **Not in CIPP** | The tenant hasn't approved the app and your CIPP doesn't manage it, so Rallied can't push the approval through CIPP | Add the tenant to CIPP (an active GDAP relationship) and Rallied pushes on its next check, or click **Grant admin consent** on the row: it opens the Microsoft page directly |
| **Processing…** | Consent is being applied | Nothing — the row updates on its own within a few minutes. If you closed the Microsoft page without approving, it clears by itself shortly |
| **Ready** · update available | The tenant approved the app before Rallied added a permission. Everything it approved keeps working; only the new capability waits. Hover the status: it names the permission, when it was added and what it enables | With CIPP, or with the two permissions from Step 2 in that tenant: nothing, Rallied applies it on its next check. Otherwise, when convenient: add the permission to the app registration if it is not there and click **Grant admin consent** on the row |
| **Approval needed** | The tenant's approval lacks one of Rallied's original permissions (it predates all of them, a push only partly landed, or a permission was removed), so tools fail there | Click **Grant admin consent** on that row and approve again — the Microsoft page grants everything the app declares today |
| **Finishing setup…** | Consented; Rallied is assigning the directory roles itself with the two permissions from Step 2 (without CIPP, roles are part of the status) | Nothing — see propagation below. If it stays for more than a day, contact Rallied |
| **Needs access method** | Consented, but Rallied has no way to assign the roles in this tenant | Connect CIPP or add the two permissions from Step 2 (**Continue setup** on this page), or [assign the roles manually](#alternative-assign-the-directory-roles-manually) |
| **Ready** | Everything in place | Nothing |
There is no refresh to click. Once a day Rallied lists your tenants again: a new tenant is verified and added, a tenant still being set up is re-checked (a role you assigned in Entra, a consent approved in the portal), and a **Ready** tenant is left alone — nothing changes there on its own. Two exceptions: when Rallied adds a permission to its required set, every tenant is checked once more so the update shows; and an hour after a consent pushed through CIPP didn't land, that tenant is checked again. If Microsoft ever refuses one of Rallied's calls in a tenant (consent revoked, a role removed), that tenant is re-checked at that moment and its status corrected. **Sync from Microsoft** does the whole picture right now: every tenant verified, new ones picked up.
Microsoft caches role permissions for **30 minutes to 2 hours** after a role is assigned. A tenant can read **Finishing setup…** for a while after Rallied assigned the role, and tools may return 403 during that window even when everything is correct.
#### Which roles count
Password resets no longer depend on a role once the tenant has approved `User-PasswordProfile.ReadWrite.All` (part of the required set since October 2026): with that permission, the Rallied app resets a non-admin user's password with no directory role at all. The roles below still matter for enabling, disabling and deleting users, for tenants whose approval predates that permission, and as the second path for resets.
Rallied assigns **User Administrator** when it sets a tenant up itself. If you assign roles manually, any role Microsoft lists as able to reset a non-admin user's password works for password resets: **Global Administrator**, **Privileged Authentication Administrator**, **User Administrator**, **Authentication Administrator**, **Helpdesk Administrator** or **Password Administrator**. The first four also allow disabling, enabling and deleting users; Helpdesk Administrator and Password Administrator do not. The verification records which one it found.
If Microsoft rejects a password reset, enable/disable or deletion in a tenant (`403 Authorization_RequestDenied`) and you have [CIPP](/integrations/cipp) connected, Rallied retries the same change through CIPP, which acts under your GDAP roles. A CIPP password reset generates its own password, so the agent shares the password (or one-time link) from CIPP's result, not the one it proposed. If CIPP isn't connected or also fails, the step fails after the technician's approval and the agent escalates the ticket, naming the tenant and the role to assign. Rallied does not refuse the request up front on its own records: when a verification could not see a role, the next check after you assign one corrects the status.
Rallied only retries through CIPP after a 403. A timeout or server error is never retried, because the first change may already have landed. A self-service password reset by an end user is not retried through CIPP either, because the end user can't be shown the generated password. A technician runs that reset instead.
**Done!** When a tenant reads **Ready**, the agent can manage users, groups, passwords, and mailboxes for that customer. Confirm by asking it to list users or distribution groups for that company.
### Alternative: assign the directory roles manually
If you don't want to add the two permissions from Step 2 to your app, consent still works — but Rallied can't assign the roles for you. Assign them yourself in each customer tenant: in Entra, go to **Identity → Roles & admins**, open the role (**Exchange Administrator** for distribution groups, shared mailboxes, mailbox permissions and the [forwarding and inbox-rule tools](#email-forwarding-and-inbox-rules); **User Administrator** for password resets, user enable/disable and deletion — or [another role that allows them](#which-roles-count)), click **Add assignment**, switch the picker to show service principals, and add the Rallied app. The row moves to **Ready** on Rallied's next daily check, or right away after **Sync from Microsoft**. This requires Privileged Role Administrator in the customer tenant.
***
## Email forwarding and inbox rules
A compromised account exfiltrates mail through two separate mechanisms, and Exchange tracks them independently. The agent can act on both:
* **Mailbox-level forwarding** — the forwarding setting on the mailbox itself, what admins usually mean by "a forwarding rule". The agent can set forwarding to an SMTP address (optionally keeping a copy in the mailbox) or stop it entirely. Stopping forwarding clears both the modern and legacy Exchange forwarding fields, so a rule set through the older field can't quietly keep forwarding mail.
* **Outlook inbox rules** — client-side rules created in Outlook that forward, redirect, delete, or move mail. These don't appear in mailbox-level forwarding settings, which makes them the more common account-takeover vector. The agent can list a mailbox's rules (including what each one does) and remove a specific rule.
A typical ticket: a security alert flags suspicious auto-forwarding on a user's mailbox. The agent checks mailbox-level forwarding, lists the inbox rules, and removes whatever is exfiltrating mail.
These are the standard containment levers for business email compromise (BEC). Setting or removing mailbox forwarding and removing an inbox rule require technician approval by default, and end users can never run them. Listing inbox rules is read-only, so end users can ask the agent why their mail is going somewhere else and get an answer about their own mailbox.
These tools use the direct Exchange path, so the tenant needs the Exchange Administrator role assigned to the Rallied app — which Rallied does itself once you've approved consent with the two permissions from [Phase 3, Step 2](#step-2-choose-how-rallied-gets-access), or which you can [assign manually](#alternative-assign-the-directory-roles-manually). They are not yet available for tenants whose Exchange access goes through CIPP.
***
## SharePoint and OneDrive
The agent can handle the common SharePoint tickets: "where is this file", "I deleted a folder", and "give Sam access to the Finance folder". These tools work on every connection path, and need no permission beyond `Sites.FullControl.All` from the [required set](#permissions-rallied-requires).
| Task | What the agent does | Default policy |
| - | - | - |
| Find a site and its libraries | Searches sites by name and lists a site's document libraries | Auto |
| Browse and search files | Lists a folder's contents, searches a library by name, and reads a file or folder's details | Auto |
| Check who has access | Lists a site's permissions, or the people, groups, and sharing links on one folder or file | Auto |
| List deleted items | Lists a site's recycle bin, with who deleted each item and when | Auto |
| Restore deleted items | Restores up to 20 files or folders from a site's recycle bin to their original location | Approval needed |
| Grant access to a folder or file | Gives a person or group read or write access, with no email and no sharing link | Approval needed |
| Remove access to a folder or file | Removes one person's, group's, or sharing link's access | Approval needed |
| Grant access to a site or library | Gives a person Read, Contribute, or Edit on a whole site or one library | Approval needed |
A typical request from a technician:
```text theme={"system"}
Restore the "Q3 Invoices" folder that was deleted from the Finance site yesterday.
```
The agent lists the site's recycle bin, finds the folder, and proposes the restore. The approval plan names each item and the folder it returns to.
Keep these limits in mind:
* **Restore and site-level grants need CIPP.** Microsoft Graph can't restore SharePoint or OneDrive for Business recycle-bin items, and can't add a person to a site's permissions. Rallied runs these through [CIPP](/integrations/cipp): restore needs CIPP 10.6.0 or later, and site or library grants need CIPP 10.9.0 or later. Without CIPP, the agent explains why it can't do the change.
* **For a Team or Microsoft 365 group site, add the person to the group.** Adding the user to the site's group is the usual way to grant site access, and it doesn't need CIPP.
* **The person must already exist in the tenant.** The agent can grant access to members, and to existing guests. Microsoft doesn't let an app invite a new guest.
* **Inherited access is removed where it's set.** The agent can only remove a permission set directly on that folder or file. It never removes the site's Owners permission, and it can't remove site-level access. A technician does that in SharePoint or CIPP.
* **No file content.** The agent reads names, paths, sizes, dates, and who has access. It never reads file content, download links, or sharing link URLs.
End users can ask which document libraries their company's site has. Browsing files, reading permissions, and every write are technician-only.
## Licensed shared mailboxes
When you convert a user mailbox to a shared mailbox, Microsoft 365 keeps the user's license assigned until someone removes it. A shared mailbox under 50 GB doesn't need a license, so each forgotten one is probably a seat you're still paying for.
The agent can check this across every customer on your CSP contract in one request. Ask it from [Chat](/dashboard/chat), for example:
```text theme={"system"}
Find any shared mailboxes across our customers that still have a license assigned.
```
For each licensed shared mailbox, the agent reports the customer, the account name, and the licenses it holds. You can also ask for counts, like "how many per customer" or "how many of each license".
Keep these points in mind when you read the results:
* **A result is a candidate, not a verdict.** A shared mailbox does need a license when it has an online archive, is on litigation hold, or is over 50 GB. The agent reports archive and litigation hold status, but not mailbox size, so check size before you remove a license.
* **License names are Microsoft's internal part numbers.** For example, Business Premium is `SPB` and Exchange Online Plan 2 is `EXCHANGEENTERPRISE`. The agent translates them for you.
* **No costs are included.** To see what the licenses cost, ask the agent to check your [Pax8](/integrations/pax8) subscriptions.
* **Large MSPs take several passes.** The agent reads Exchange and Microsoft Graph for every customer, so on a large contract it continues in batches until it has checked everyone.
* **Some customers may not be checked.** The agent tells you how many customers it couldn't check and why. A customer that wasn't checked is not the same as a customer with no licensed shared mailboxes.
This check reads Exchange directly, so each customer tenant needs admin consent for `Exchange.ManageAsApp` and the Exchange Administrator role assigned to the Rallied app ([assign the directory roles manually](#alternative-assign-the-directory-roles-manually), or let Rallied assign it with the two permissions from [Phase 3, Step 2](#step-2-choose-how-rallied-gets-access)). The agent lists tenants without that access as not checked.
This check is read-only and runs without approval by default.
## Message trace
The agent can trace email through Exchange Online to answer "did my email arrive?" and "is this email safe?". For each matching message, it reports when it was received, the sender, recipient, subject, delivery status, and the sending server's IP address. For a suspicious email, that IP shows the real origin.
A typical request from a technician:
```text theme={"system"}
Did the invoice from billing@vendor.com reach sam@acme.com yesterday? If not, what happened to it?
```
The agent filters by sender, recipient, delivery status (for example `Delivered`, `Failed`, `FilteredAsSpam`, or `Quarantined`), subject, or Message-ID.
Keep these limits in mind:
* **Last 90 days, 10 days at a time.** Microsoft keeps trace data for 90 days and returns at most 10 days per query. Without dates, the agent searches the last 48 hours.
* **Same access as other Exchange tools.** The trace uses the Exchange Administrator role assigned to the Rallied app, so it needs no extra permission. Tenants whose Exchange access goes through [CIPP](/integrations/cipp) are traced through CIPP.
* **Technicians only.** A trace shows other people's mail metadata, so end users can't run it.
Message trace is read-only and runs without approval by default.
## Conditional Access policies
The agent can read a tenant's Conditional Access policies and named locations. Use them to answer "why is this user asked for MFA?" or "why is this sign-in blocked?", or to audit which policies exclude a user or group.
For each policy, the agent reports its state (enabled, disabled, or report-only), who and which apps it applies to, its conditions, and its grant and session controls. Users, groups, roles, and locations show by name where Rallied can resolve them. Named locations show their IP ranges or countries and whether they're marked trusted.
Reading Conditional Access needs the Microsoft Graph application permission `Policy.Read.All`, which Rallied's app doesn't request. When a tenant's token lacks it, Rallied answers through [CIPP](/integrations/cipp) if it's connected. Otherwise, the agent tells you it can't read the policies.
These tools are read-only, run without approval by default, and are technician-only.
***
## Optional: Connect CIPP
If your MSP already runs [CIPP](https://docs.cipp.app), connecting the [CIPP integration](/integrations/cipp) is the fastest way to get every customer tenant ready:
* **Admin consent is pushed for you.** The moment you connect CIPP, Rallied pushes consent into every tenant still waiting; every later Sync does the same for new tenants. No per-row clicking. **Grant admin consent** stays available on any row CIPP can't reach — it retries CIPP first and only opens the Microsoft consent page if CIPP rejects it.
* **Exchange tools without the Exchange Administrator role per tenant.** The agent picks up distribution groups and shared mailboxes through CIPP automatically. [Email forwarding and inbox rule tools](#email-forwarding-and-inbox-rules) are the exception: they still need the role assigned directly.
* **SharePoint through CIPP.** "Who has access to this site" is read through CIPP where the tenant hasn't approved `Sites.FullControl.All` yet. CIPP also unlocks [restoring deleted SharePoint items and granting site access](#sharepoint-and-onedrive).
* **User changes when a role is missing.** If Microsoft refuses a password reset, enable/disable, or deletion with a 403, Rallied retries it through CIPP. See [Which roles count](#which-roles-count).
CIPP is optional. Without it, choose **Approve yourself** in Phase 3 — one consent click per tenant, and Rallied handles the roles.
Setup, credential rotation, and troubleshooting live on the [CIPP integration page](/integrations/cipp).
***
## Permissions Rallied requires
This is the set Rallied needs in each customer tenant today, for reference.
**Nothing to add on your side.** With either option in [Phase 3, Step 2](#step-2-choose-how-rallied-gets-access) — CIPP, or the two setup permissions — Rallied grants every permission below in each tenant on its own. The list is here so you always know what Rallied holds. If neither option works for your MSP, you can add them to the app registration yourself (**API permissions → Add a permission**, type **Application**) and click **Grant admin consent** on each tenant's row.
| API | Permission | What it enables |
| - | - | - |
| Microsoft Graph | `User.ReadWrite.All` | User management, enable and disable accounts |
| Microsoft Graph | `Group.ReadWrite.All` | Entra group management |
| Microsoft Graph | `Directory.Read.All` | Read licenses, SKUs, organization info. In your partner tenant it also lists your customer tenants |
| Microsoft Graph | `UserAuthenticationMethod.Read.All` | MFA status checks |
| Microsoft Graph | `IdentityRiskyUser.Read.All` | Risky user detection |
| Microsoft Graph | `AuditLog.Read.All` | Sign-in log diagnostics (lockout confirmation, suspicious sign-in investigation) |
| Microsoft Graph | `Sites.FullControl.All` | SharePoint and OneDrive: find sites, browse libraries, read who has access, and grant or remove access to a folder or file |
| Microsoft Graph | `User-PasswordProfile.ReadWrite.All` | Password resets. With it, resets of non-admin users work without any directory role on the Rallied app (added October 2026) |
| Office 365 Exchange Online | `Exchange.ManageAsApp` | Distribution groups, shared mailboxes, mailbox permissions |
Plus two directory roles on the Rallied app: **Exchange Administrator** and **User Administrator**. User Administrator remains assigned as a second path for resets and covers enable, disable and delete; see [which roles count](#which-roles-count) and [how to assign them yourself](#alternative-assign-the-directory-roles-manually).
When Rallied adds a permission to this set, tenants that approved before keep working and show **Ready · update available** (the status names the permission, the day it was added and what it enables). With CIPP or the setup permissions, Rallied applies it on its next check; otherwise add it to the registration and click **Grant admin consent** on the row again when convenient.
***
## Who needs which role
| Phase | Who | Required Role |
| - | - | - |
| 1.1–1.3 — App registration & permissions | Partner tenant admin | Application Developer (minimum), Application Administrator, or Global Administrator |
| 1.4 — Grant consent in partner tenant | Partner tenant admin | **Global Administrator** or **Privileged Role Administrator** |
| 2 — Connect in Rallied | MSP admin in Rallied | Rallied MSP integration access |
| 3.2 — Approve a tenant yourself | Customer admin or MSP via GDAP | **Global Administrator** or **Privileged Role Administrator** of the customer tenant |
| Alternative — assign the directory roles manually | Customer admin or MSP via GDAP | **Privileged Role Administrator** of the customer tenant |
| [Connect CIPP](/integrations/cipp) (optional) | MSP admin in Rallied + CIPP admin | Rallied MSP integration access + CIPP **admin** role on the API integration |
***
## Troubleshooting
Rallied authenticates with a client secret (no signed-in user), so only **Application permissions** grant anything usable — **Delegated permissions** require an interactive user and silently produce a token with no real access. Picking the Delegated tab by mistake in Phase 1, Step 3 won't error at that step or at consent time; it only shows up later, as an `Authorization_RequestDenied` ("Insufficient privileges...") error when syncing tenants or running tools. Go back to API permissions, remove the Delegated ones, and re-add them under **Application permissions**, then grant admin consent again.
If Graph permissions are correctly set (the above isn't the issue) and other tools work fine, the tenant's approval predates `User-PasswordProfile.ReadWrite.All` (the row reads **Ready · update available**; approving the update fixes resets on its own) and the Rallied app holds no role in that tenant that allows password resets (see [which roles count](#which-roles-count)) — the Status column reads **Finishing setup…** or **Needs access method**, and the tooltip names the missing role. Unlike a missing Graph permission, this fails silently at consent time too: the app can technically call the password reset endpoint, Microsoft just rejects the specific action. Rallied assigns User Administrator itself (on its daily check, or on Sync) when the two permissions from Phase 3, Step 2 are on your app. With CIPP connected, roles are not assigned and the tenant still reads **Ready**: the reset is retried through CIPP instead, so a 403 that still reaches the ticket means CIPP could not do it either — check that the tenant is in CIPP's **Tenants** list and that your GDAP relationship includes **User Administrator** (resetting that user from the CIPP UI is the quickest check). Allow for propagation either way; the next check records the role once Microsoft shows it.
Reading who has access to a specific site (`msgraph-get-site-permissions`) needs `Sites.FullControl.All`, which the tenant consented before it was part of the required set. The row reads **Ready · update available**. With CIPP connected, or with the two setup permissions from Phase 3, Step 2 in that tenant, Rallied grants it itself (on its daily check, on Sync, or the moment a tool call is refused there). Otherwise, when convenient: add the permission to the app registration and click **Grant admin consent** on the row — the consent page grants everything currently declared on the app.
When the app declares Microsoft Graph **application permissions**, only Global Administrator or Privileged Role Administrator can grant consent. Cloud Application Administrator and Application Administrator are insufficient.
Assigning a directory role (Exchange Administrator, User Administrator) in the partner tenant does **not** grant that role in customer tenants. Each customer tenant requires its own assignment.
To perform consent + role assignment via GDAP (without a customer admin), the GDAP relationship must include Global Administrator or Privileged Role Administrator. Verify your GDAP template before attempting.
Microsoft caches role permissions for 30 minutes to 2 hours after assignment. Wait; Rallied's next daily check picks the role up, or click **Sync from Microsoft** to check now. This is expected behavior.
The display name set during app registration (Phase 1, Step 1) is what appears in role pickers across all tenants. If you can't find it, search by the Application (client) ID instead.
`AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID...`
The Certificates & secrets page shows two similar-looking values side by side: **Value** and **Secret ID**. Rallied needs the **Value**, not the Secret ID — double check which one you copied. If in doubt, generate a new secret and copy the Value right away, before navigating away from the page.
`AADSTS500113: No reply address is registered for the application.`
The app has no Redirect URI. Go to the app's Overview page in Entra, click **Add a Redirect URI**, add one as type **Web** (any URL you control works — it isn't used at runtime), then try the consent again.
Microsoft's consent page grants exactly what the Rallied app **declares** in your app registration at that moment. If you added the permission to the registration after that approval, or added it as **Delegated** instead of **Application**, the approval didn't include it. Check **App registrations → the Rallied app → API permissions** in your partner tenant (type Application, status Granted), then approve the tenant again. Also make sure the account approving is a Global Administrator or Privileged Role Administrator of that customer tenant, or your GDAP account with one of those roles: otherwise Microsoft refuses the approval and nothing changes.
Rallied added a permission to its required set since this tenant last approved the app (hover the status: it names the permission, the day it was added and what it enables). This isn't an error — everything already approved keeps working exactly as it did; only the new capability waits. With CIPP connected, or with the two setup permissions from Phase 3, Step 2 in that tenant, Rallied applies it on its next check and the suffix goes away on its own. Otherwise, when convenient: add the permission to the app registration if it isn't there, then click **Grant admin consent** on the row and approve again. A line above the table says the same for all affected tenants at once.
**Processing…** means a consent was sent and Rallied is waiting for Microsoft to reflect it — normally a minute or two, up to 15 minutes when it went through CIPP. If you opened the Microsoft consent page and closed it without approving, the row clears by itself within a few minutes and **Grant admin consent** comes back.
CIPP-specific issues (invalid client secret, a tenant CIPP can't reach, Exchange still pending) are covered in the [CIPP troubleshooting section](/integrations/cipp#troubleshooting).
***
## Reference links
* [Register an application](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app)
* [Multi-tenant app setup](https://learn.microsoft.com/en-us/entra/identity-platform/howto-convert-app-to-be-multi-tenant)
* [Configure API access](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-configure-app-access-web-apis)
* [Admin consent endpoint](https://learn.microsoft.com/en-us/entra/identity-platform/v2-admin-consent)
* [Grant tenant-wide consent](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/grant-admin-consent)
* [User and admin consent overview](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/user-admin-consent-overview)
* [App-only auth in Exchange Online](https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2)
* [Application RBAC for Exchange](https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac)
* [Assign Entra roles](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/manage-roles-portal)
* [Exchange Administrator role](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#exchange-administrator)
* [GDAP introduction](https://learn.microsoft.com/en-us/partner-center/customers/gdap-introduction)
* [GDAP least-privileged roles](https://learn.microsoft.com/en-us/partner-center/customers/gdap-least-privileged-roles-by-task)
* [CIPP integration in Rallied](/integrations/cipp)
* [CIPP documentation](https://docs.cipp.app)
# Microsoft Teams Integration
Source: https://docs.rallied.ai/integrations/microsoft-teams
The Microsoft Teams integration puts your helpdesk inside your clients' Teams. Employees describe their problem in a 1:1 chat with a bot that carries **your brand**, and the agent files the ticket in your PSA. Every ticket gets its own named group chat where the requester and your technicians talk through the ticket without leaving Teams.
Microsoft Teams is connected in **MSP Settings → Integrations**. Its configuration (branding, app package, ticket intake routing, and tenant links) lives on the integration's detail page and is also available from **MSP Settings → Teams**.
## Prerequisites
* A connected PSA that supports ticket intake. Teams intake files tickets in **ConnectWise Manage** or **HaloPSA** (whichever your MSP has connected).
* The **Microsoft 365 Tenant ID** of each client you want to enable
* For the auto-setup path: a tenant admin willing to grant admin consent and complete a sign-in that publishes the app.
## How to connect
Connecting the integration is the ON switch for the entire Teams surface: app package, branding, tenant links, message intake, and ticket chats all require it.
In **MSP Settings → Integrations**, find the Microsoft Teams card and click **Connect**. There are no credentials to enter. The bot identity is provided by Rallied.
Go to **MSP Settings → Teams** and click **Branding**. Set the app display name (defaults to your MSP name), an accent color, and your logo. One logo upload produces both icon sizes Teams requires (192×192 color and 32×32 outline).
In the client table on the Teams page, click **Link tenant** and paste that client's Microsoft 365 Tenant ID. If you have the **Microsoft 365** integration connected, tenant IDs are pre-filled from its GDAP sync and you just confirm each link. The row shows **Linked — awaiting install**. Linking is what ties messages from that tenant to the right client. Rallied drops messages from unlinked tenants.
## Setup wizard and guided tour
After you connect the integration, a **setup wizard** walks you through the remaining steps. The wizard opens automatically for new connections and is mandatory until the first client is fully provisioned. The steps are:
1. **Branding** (optional): set display name, accent color, and logo.
2. **Ticket routing** (required): pick the PSA, board, and optional new-ticket status where intake tickets are created.
3. **Link your first client** (required): choose a client and link their Microsoft 365 tenant.
4. **Publish and admin consent** (required): grant admin consent and publish the app to the client's tenant catalog.
After you finish the wizard, a **guided tour** spotlights the next client's row on the configuration tab. This reminds you to link and grant consent for each additional client. The tour runs once and marks itself seen. You can always return to any unfinished setup from the **Continue setup** banner on the integration detail page.
## Tenant setup: auto-setup and manual
After linking a tenant, choose how to get the app into the client tenant. Each row supports two paths:
### Auto-setup (recommended)
Click **Admin consent** on the row. The consent screen asks the client's tenant admin to approve the app. After consent is verified, the admin is signed in a second time so Rallied can publish the white-labeled app package into the tenant's catalog (Microsoft requires this sign-in for catalog writes). The app is then available to users.
If consent succeeds but publishing fails, the row shows **Publish failed** with the error. Click **Republish** to retry (for example, after a network error or when you update branding). If the app was already published and you bumped the package version, click **Publish update** to push the new version.
You can also copy the consent link or the publish link from the row's **More actions** menu to forward to the client's admin instead of opening it yourself.
If the app gains new permissions later (for example, chat rename), already-consented tenants need **Re-consent** to grant the new scopes. This option is also available in **More actions**.
### Manual upload
Click **Download app** to generate one white-labeled Teams app package (a `.zip`) that carries your brand to every client tenant. Send the package to the client's Teams admin. They upload it to their tenant's app catalog and roll it out to their users. When the app is installed, the row flips to **Installed** automatically.
If you change branding later, tenants using auto-setup get the update on the next **Republish** or **Publish update**. Tenants using manual upload need the admin to re-upload a new package with a higher version number.
A row's **Setup** column tells you which path is in use: **Auto-setup ✓** for consent + published, **Manual** for the hand-upload flow, **Publish failed** if consent completed but the publish step did not, or **Consented** if consent is recorded but the publish is still pending.
## Ticket intake routing
The **Ticket intake** section on the Teams configuration page controls where tickets filed from Teams land in your PSA:
* **PSA** — which connected PSA receives Teams intake tickets. The selector shows every connected intake-capable PSA. Pick one explicitly or leave it on **Automatic** to use the first available. If the selected PSA disconnects later, a paused callout appears until you pick again.
* **Board** — the board where the agent creates new Teams tickets. With ConnectWise Manage connected, you pick from a live list of your service boards. HaloPSA shows its ticket types.
* **New-ticket status** (optional, ConnectWise Manage only) — the status new Teams tickets start in. Leave it on **Board default** to use the board's own default, or pick a status to keep Teams intake tickets in a dedicated status. Changing the board clears the status pick, since statuses belong to a board.
* **Ticket type** (HaloPSA only, required) — the Halo ticket type for Teams intake. Without it, filing fails.
Click **Save intake routing** to apply. Saving requires the `integrations:write` capability. Read-only users see the saved values but can't change them.
## How employees use it
### Filing a ticket
Employees open a 1:1 chat with your branded bot and describe their problem. The bot asks follow-up questions until it knows the affected system, the symptom, and the impact, then files a ticket in your PSA. The requester's identity comes from their verified Teams sign-in and is attached as the ticket contact automatically. The first reply in every conversation includes an AI disclosure.
Employees can also ask "what tickets do I have?" in the 1:1 chat to list their own open tickets. Tickets opened through Teams show a **Go to chat** button when a dedicated group chat exists.
### Opening a ticket chat for an existing ticket
If an employee has an open ticket that was filed by email or phone, they can ask to open a dedicated Teams chat for it. The bot creates the chat and sends them a **Go to chat** link. This only works for tickets that belong to them.
### The per-ticket chat
When a ticket is created or opened as a chat, Rallied creates a dedicated named group chat through Microsoft Graph. The chat is named `#{ticket number} — {summary}` and contains exactly two members: the bot and the requester.
The chat is a live, two-way bridge to the ticket:
* **Requester writes in the chat** — the bot posts the message to the ticket as a client-facing note, attributed to the requester. Only messages from the original requester are relayed; messages from anyone added later are answered with a notice and dropped.
* **A technician or the agent posts a client-facing note on the ticket** — the note text appears in the chat, verbatim. Internal notes are never relayed.
* **Ticket status changes** — when a ticket moves to a new non-closed status, a status update card appears in the chat.
* **The ticket is closed** — the chat is renamed to `[Closed] #{ticket number} — {summary}` and the bot posts a closing card.
# N-able N-central
Source: https://docs.rallied.ai/integrations/n-central
Have the agent triage N-able N-central alerts and run automation tasks against managed devices without a technician needing to open the N-central console.
Connect N-able N-central so the agent can query devices, run scheduled tasks, manage org and device custom properties, view active issues, and generate patch reports across every customer (service organization) in your N-central instance.
N-central is configured in **Settings → Integrations**.
## How to connect
N-central uses a long-lived **JWT token** generated from the N-central UI. Rallied exchanges the JWT for short-lived access and refresh tokens automatically, and re-authenticates with the stored JWT if the refresh token expires.
Sign in to your N-central instance as a user with API access. Open your **User Profile → API Access** (or **Administration → User Management**) and generate a JWT token.
The JWT lives until the user's password expires (default 90 days) or the token is explicitly regenerated, so pick a service account whose password rotation cadence you control.
In Rallied, go to **Settings → Integrations**.
Find the N-able N-central card and click **Connect**. A credentials form appears.
Fill in:
* **Instance URL** — your N-central server, e.g. `https://yourserver.n-able.com` (no trailing slash; HTTPS required)
* **JWT Token** — the JWT you generated in step 1
Click **Save**. Rallied calls `/api/auth/authenticate` with the JWT, stores the resulting access + refresh tokens, and the card shows **Connected** when complete.
Rallied stores the JWT permanently and uses it to re-authenticate if the refresh token expires (typically every 25h). If you regenerate the JWT in N-central or the source user's password expires, the connection will eventually fail. Open the N-central detail page, click **Update connection**, and enter a fresh JWT.
## How the agent uses it
When a request involves a customer or device managed in N-central (**"what's wrong with the file server at Acme?"**, **"push the cleanup script to all of Globex's workstations tonight"**, **"give me a patch report for last week"**), the agent typically:
1. Resolves the customer with `n_central-list-service-orgs` or `n_central-list-customers`.
2. Finds the device with `n_central-list-devices` (and `n_central-get-device` for full asset info).
3. Pulls health data from `n_central-list-active-issues`, `n_central-get-device-service-monitor-status`, `n_central-get-device-lifecycle-info`, or `n_central-get-device-assets`.
4. Runs remediation via `n_central-run-direct-task` (a pre-defined N-central script with input parameters) and follows up with `n_central-get-task-status` / `n_central-get-task`.
5. For reporting, it kicks off `n_central-generate-patch-report` and retrieves it with `n_central-get-report`.
For anything not covered by a typed tool, the agent can fall back to raw API calls via `n_central-api-get`, `-post`, `-put`, and `-delete`.
## Tools
| Tool | Description |
| - | - |
| `n_central-list-service-orgs` | List service organizations in the N-central instance |
| `n_central-list-customers` | List customers, optionally filtered by service org |
| `n_central-create-customer` | Create a new customer |
| `n_central-list-sites` | List sites for a customer |
| `n_central-create-site` | Create a new site under a customer |
| `n_central-list-devices` | List managed devices, optionally filtered by customer or site |
| `n_central-get-device` | Get full details for a specific device |
| `n_central-get-device-assets` | Get hardware and software asset details for a device |
| `n_central-get-device-lifecycle-info` | Get lifecycle/warranty info for a device |
| `n_central-get-device-service-monitor-status` | Get service monitor status for a device |
| `n_central-get-device-custom-properties` | List custom properties on a device |
| `n_central-get-device-custom-property` | Get a single device custom property |
| `n_central-update-device-custom-property` | Update a device custom property |
| `n_central-list-org-custom-properties` | List custom properties on an organization |
| `n_central-update-org-custom-property` | Update an organization custom property |
| `n_central-list-active-issues` | List active issues across devices |
| `n_central-list-job-statuses` | List recent job statuses |
| `n_central-list-scheduled-tasks` | List scheduled tasks |
| `n_central-list-device-scheduled-tasks` | List scheduled tasks for a device |
| `n_central-run-direct-task` | Run a direct script/task on one or more devices with input parameters |
| `n_central-get-task` | Get a task definition |
| `n_central-get-task-status` | Get the status of a task execution |
| `n_central-get-task-details` | Get detailed task execution info |
| `n_central-generate-patch-report` | Generate a patch status report |
| `n_central-get-report` | Retrieve a generated report |
| `n_central-list-device-filters` | List configured device filters |
| `n_central-get-registration-token` | Get an N-central agent registration token |
| `n_central-list-users` | List N-central users |
| `n_central-create-user-role` | Create a new user role |
| `n_central-create-device-access-group` | Create a device access group |
| `n_central-api-get` / `-post` / `-put` / `-delete` | Generic API calls for endpoints without a typed tool |
Default policies are seeded per tool — read-only lookups default to **auto**, mutations and task runs default to **approval needed**. Tune them on the **N-able N-central** integration detail page.
## Policies
N-central is an integration. Per-tool policies are configured on the **N-able N-central** integration detail page (open it from **Settings → Integrations**).
See [Approval settings](/dashboard/policies) for an overview.
# NinjaOne
Source: https://docs.rallied.ai/integrations/ninjaone
Close endpoint tickets without opening NinjaOne: the agent diagnoses alerts, runs scripts, patches software, and remediates devices from inside the ticket.
Connect NinjaOne and Rallied's agents can look at any managed device across all your organizations, figure out what's going on, and take action: restart a stuck service, reboot a kiosk, run one of your library scripts against a whole customer, close out the alert, open a ticket. Your techs stop clicking through 30 screens to answer **"is the print server up?"** and start reviewing what the agent already found.
Concrete wins after you connect:
* **Alerts triaged before your tech opens the ticket.** When a NinjaOne alert fires, the agent already knows what device, what software, what recent activity, and what to try first.
* **Remediation without a swivel chair.** The agent runs your existing NinjaOne library scripts on the right devices — no clicking through NinjaOne to launch them one at a time.
* **You always sign off on writes.** Anything that changes state on a device (rebooting, running a script, dismissing an alert) needs technician approval by default. The agent shows exactly what it wants to do first.
NinjaOne is configured in **Settings → Integrations**.
## Connect NinjaOne
You'll create an API app inside NinjaOne, paste the credentials into Rallied, and authorize the app in a NinjaOne consent popup. NinjaOne uses OAuth with a per-MSP app, so there's no shared vendor app to consent to.
Sign in to NinjaOne as an administrator and go to **Administration → Apps → API → Add**. Create a new app with:
* **Application platform** — Web
* **Redirect URI** — the callback URL shown on the Rallied connect form
* **Scopes** — `monitoring`, `management`, `control`
Save the app and copy the **Client ID** and **Client Secret**. The secret is only shown once.
In Rallied, go to **Settings → Integrations**, find the NinjaOne card, and click **Connect**. Fill in:
* **Client ID** and **Client Secret** from your NinjaOne API app
* **Region** — the NinjaOne instance your tenant lives on (`app.ninjarmm.com`, `us2.ninjarmm.com`, `eu.ninjarmm.com`, `oc.ninjarmm.com`, or `ca.ninjarmm.com`)
Click **Save**.
A popup opens against NinjaOne. Sign in if prompted and approve the requested scopes. Once NinjaOne redirects back, the card shows **Connected**.
Rallied refreshes the access token automatically. If NinjaOne stops accepting the token, for example because someone revoked the API app, click **Reauthorize** on the NinjaOne detail page and approve the app again. If you rotate the client secret in NinjaOne, click **Update connection** on the detail page and enter the new secret. Rallied opens the authorization popup afterwards if NinjaOne needs a fresh approval. Both options keep your approval settings and synced clients.
## What the agent can do
The agent can read from any managed device — recent activity, installed software, running services, disks, volumes, alerts — without asking. For anything that changes state on a device it stops and asks for technician approval by default: restarting a service, rebooting a device, running a script, dismissing an alert, or updating a ticket.
So a typical flow after an alert or a user request looks like: the agent identifies the right organization and device, gathers the context your tech would have collected anyway, drafts a plan, and either resolves it or hands you a one-click approval to run the fix.
## Library scripts and built-in actions
The agent can run two kinds of automation on a device:
* **Library scripts** — the custom scripts your admins have added under **Administration → Library → Automation** in NinjaOne.
* **Built-in actions** — the actions NinjaOne ships with, like **Reboot** or **Flush DNS**.
The agent always checks what's available on the device before running anything, and it identifies each entry by its ID rather than its name, so a renamed script never runs the wrong thing.
NinjaOne's script library also lists "native" entries that sit behind the built-in actions. Those entries can't be run as scripts through the API — they fail every time. The agent knows this and runs the built-in action itself instead. Your own custom library scripts run fine.
A few actions are OS-specific:
* **Restarting a service** only works on Windows devices — Linux and macOS don't have Windows services, and NinjaOne rejects the request on those platforms.
* **The one-click reboot** works on Windows and macOS. Linux devices are rebooted through the built-in **Reboot** action instead; the agent checks the device's OS first and picks the right route on its own.
## Tickets
The agent can open and update NinjaOne tickets to leave a paper trail next to its device work:
* When creating a ticket, it can set the type, priority, and severity, and link the ticket to a specific device. If it doesn't specify a ticket form, the organization's default form (or the first active one) is used.
* When updating a ticket's status, priority, or subject, everything else on the ticket is preserved. NinjaOne's API replaces the whole ticket on update, so Rallied fetches the current ticket first and re-sends it with only the changes applied.
## Running custom bash scripts (Linux and macOS)
Out of the box NinjaOne only lets you run scripts that already exist in your script library. If you want the agent to run **ad-hoc** bash on Linux or macOS endpoints (one-liners a tech would normally SSH in to run), set up a one-time bridge script and paste its ID into the NinjaOne integration page.
In NinjaOne, create a new **Mac/Linux** script with:
* **One String parameter**
* **Body** — `echo "$1" | base64 --decode | bash`
Save it and copy the numeric **Script ID** from the details page.
In Rallied, open **Settings → Integrations → NinjaOne** and find the **Bash Runner Script** section. Paste the Script ID and click **Save**.
Once configured, the agent can run any custom bash on Linux or macOS devices through this bridge. To turn it off later, clear the Script ID field and save.
Bash runs are asynchronous: NinjaOne doesn't return the output directly. The agent reads the result from the device's activity feed once the device reports back, usually within 10–30 seconds.
Custom bash runs as root by default, which makes it the highest-risk action in the integration. It always requires technician approval, and the exact script the agent wants to run is shown in the approval request. Review it before approving.
The bash runner is Linux and macOS only. For Windows devices, the agent uses your existing NinjaOne library scripts and built-in actions.
## Approval settings
You control which NinjaOne actions the agent takes on its own vs. which need a technician sign-off, on the NinjaOne page under **Settings → Integrations**. Defaults are read-freely, ask-for-writes:
* **Auto-approve** — listing and inspecting devices, organizations, disks, volumes, software, services, activity, alerts, and scripts. Creating tickets. Reading ticket logs.
* **Needs approval** — starting/stopping/restarting a service, rebooting a device, running a library script or ad-hoc bash, dismissing an alert, updating a ticket, and any generic write against the NinjaOne API.
See [Approval settings](/dashboard/policies) for the bigger picture.
# One-Time Secret
Source: https://docs.rallied.ai/integrations/onetime-secret
Keep temporary passwords and recovery codes out of ticket history: the agent shares them as self-destructing One-Time Secret links employees can open once.
Connect [One-Time Secret](https://onetimesecret.com) and when Rallied's agents deliver a temporary password, a recovery code, or any other sensitive value to an end user, they hand off a single-use link instead of leaving the cleartext value in a ticket note, email thread, or chat log. The recipient opens the link once and the value is destroyed.
What you get once it's connected:
* **No credentials in your ticket history.** The agent posts the link, not the password. Your PSA stays clean of anything an auditor would flag.
* **No follow-up cleanup for your team.** No more **"go back and redact the temp password from ticket #4832"** after a reset.
* **One less tool your techs have to reach for.** The agent generates the link automatically when it does a password reset or hands off a recovery code — your techs don't have to remember to use OneTimeSecret manually.
One-Time Secret is configured in **Settings → Integrations**.
## Connect One-Time Secret
You'll need a One-Time Secret account and an API key.
Go to [onetimesecret.com](https://onetimesecret.com) and sign in (or sign up). The free plan supports the API; paid plans raise the rate limits and add custom branding.
From the top-right menu open **Account**, scroll to the **API** section, and click **Generate Key** (or **Reset Key** if you already have one). Copy the key.
In Rallied, go to **Settings → Integrations**, find the **One-Time Secret** card, and click **Connect**. Fill in:
* **Username (account email)** — the email address on your One-Time Secret account.
* **API Key** — the key you just copied.
Click **Save**. The card shows **Connected** once the credentials check out.
That's it. There's no per-tenant or per-client setup, and no webhook to register.
## What happens when the agent needs to share a credential
When a workflow (or the agent's own reasoning) calls for delivering something sensitive to a user, like a temporary password after a reset, a recovery code, or a first-login token, the agent generates a one-time link through your One-Time Secret account and puts the **link** in front of the user instead of the value itself.
By default the link expires **24 hours** after it's created. The agent can shorten that for urgent resets or extend it up to 14 days for users who might not open it right away.
If the workflow calls for extra protection on high-sensitivity credentials (domain admin, banking portals), the agent can attach a passphrase to the link and deliver the passphrase through a different channel — for example, the link goes in the ticket and the passphrase is sent by SMS or email.
## Where the link gets delivered
The agent uses whichever channel the ticket is already on:
* **PSA ticket** — customer-visible reply on the ticket, so the user gets it in the same email thread they've been on.
The cleartext value never lands in the ticket or the chat log.
## Approval settings
Generating a one-time link is auto-approved by default, so the agent can do it without stopping. If you want a technician to review each link before it goes out, change **onetimesecret-share-secret** to **Needs approval** on the integration page. See [Approval settings](/dashboard/policies).
## If something goes wrong
If One-Time Secret returns an error when the agent tries to generate a link (rate limit, expired API key, service outage), the agent **does not** fall back to pasting the cleartext value on the ticket. It stops, posts an internal note asking a technician to deliver the credential manually, and moves on. Your customer-facing history stays clean even when the API is having a bad day.
# Integrations overview
Source: https://docs.rallied.ai/integrations/overview
Give your agent real hands: every integration you connect unlocks a set of tools it can use across your PSA, RMM, Microsoft 365, docs, identity, and chat.
Integrations give your Rallied agent real capabilities. Without them, the agent can diagnose a ticket but cannot resolve it. When you connect an integration, the agent gains a set of tools: add a note to a ConnectWise ticket, reset a Microsoft 365 password, run a NinjaOne script, look up a runbook in IT Glue. It uses them automatically as part of resolving helpdesk requests.
## How integrations work
When an employee submits a ticket or sends a message to the agent, the agent diagnoses the issue and selects the right tools to resolve it. Each tool corresponds to an API action in one of your connected integrations. The agent calls those tools on your behalf, logs every action, and routes any sensitive operations through your approval flow before executing.
**Credentials are never stored on your agent servers.** OAuth tokens and API keys are managed securely and transmitted to the agent only at runtime via the Tool Gateway.
After you connect an integration, Rallied automatically:
* Syncs the available tools from that integration into your agent's tool catalog
* Seeds sensible default policies for each tool (read-only actions run automatically; write actions require approval)
You can override any default policy from the integration's detail page — open it from **Settings → Integrations**.
## Connecting via OAuth
For integrations that use OAuth, the flow is the same every time:
Navigate to **Settings → Integrations**.
Find the integration you want to connect and click the **Connect** button.
A login window opens in the provider's own interface (Atlassian, Slack, Microsoft, etc.). Sign in and grant the requested permissions.
Once authorized, Rallied fetches the available tools and seeds default policies. The integration shows as **Connected** and the agent is ready to use it.
Some integrations use a credentials form instead of OAuth redirect. For those, you enter your API credentials (URL, keys, tokens) directly in Rallied.
## Approval flows
Every integration that can take write actions participates in the approval flow. When the agent's plan includes an action you've marked as needing approval, it posts an approval request through one of your connected approval channels:
* **ConnectWise Manage** — a note is added to the ticket
* **HaloPSA** — an action is created on the ticket
* **Autotask** — a note is added to the ticket
* **Jira** — a comment is posted on the issue (where Jira is connected)
* **Slack** — a DM is sent to the assigned technician (where Slack is connected)
Technicians can approve or deny directly from those channels. You don't need to open Rallied.
## Available integrations
Business messaging. Gives the agent a bot presence in your client's Slack workspace for employee interaction and approval notifications.
White-labeled helpdesk in Teams. Employees file tickets with your branded bot and follow each ticket in its own named chat.
Ticketing by Atlassian. The agent creates and updates Jira issues, receives new tickets via webhook, and posts approval requests as comments.
PSA platform. The agent receives new service tickets, posts notes, and routes approvals through ConnectWise.
ITIL-aligned PSA. The agent receives HaloPSA tickets, posts actions, and routes approvals through HaloPSA.
Unified PSA and RMM. Rallied's agents triage, work, and resolve SuperOps tickets. Your team approves the actions you've flagged for review.
Custom tool servers. Connect any server that implements the Model Context Protocol to extend the agent with your own tools.
### Identity & access
| Integration | Description |
| - | - |
| **JumpCloud** | Cloud directory for unified identity and device management |
| **Duo** | Multi-factor authentication and push verification |
| **Traceless** | Identity verification orchestrator that routes MFA push to Duo or Microsoft Authenticator |
| **Microsoft 365** | User, group, email, Teams, and Intune management via Microsoft Graph |
| **[CIPP](/integrations/cipp)** | Bulk admin consent for Microsoft 365 customer tenants and an Exchange fallback where the Rallied app lacks the Exchange Administrator role |
### PSA / ticketing
| Integration | Description |
| - | - |
| **ConnectWise Manage** | Ticket management, billing, and client tracking |
| **HaloPSA** | ITIL-aligned ticketing, asset management, and SLA tracking |
| **Autotask** | PSA by Datto with ticketing, billing, and CRM |
| **Syncro** | Combined RMM and PSA with built-in billing |
| **SuperOps** | Unified PSA and RMM for modern MSPs |
| **Jira** | Project and issue tracking by Atlassian |
### RMM
| Integration | Description |
| - | - |
| **NinjaOne** | Cloud-based RMM with endpoint management and remote access |
| **Datto RMM** | Remote monitoring, patch management, and endpoint automation |
| **ConnectWise Automate** | Automation-focused RMM for endpoint management |
| **Atera** | Combined RMM and PSA for small and mid-size MSPs |
| **Kaseya VSA** | IT management platform with remote monitoring and automation |
### Security & EDR
| Integration | Description |
| - | - |
| **SentinelOne** | AI-powered EDR with autonomous threat prevention and response |
| **Huntress** | Managed threat detection and response for persistent threats |
| **Blumira** | Managed SIEM and XDR with automated detection |
| **[Sophos Central](/integrations/sophos-central)** | Read-only partner access to customer firewalls and Sophos alerts |
### Backup & disaster recovery
| Integration | Description |
| - | - |
| **[Axcient x360Recover](/integrations/axcient)** | Read-only device backup health, restore points, vault replication, and job history |
### Email security
| Integration | Description |
| - | - |
| **Proofpoint TAP** | Advanced threat protection against phishing and malware |
| **Mimecast** | Email security, archiving, and continuity |
| **Abnormal Security** | AI-based email security against business email compromise |
| **IRONSCALES** | Email security platform with phishing simulation and remediation |
| **Avanan** | Cloud email and collaboration security |
| **SpamTitan** | Email filtering and spam protection for MSPs |
### Documentation & knowledge
| Integration | Description |
| - | - |
| **Hudu** | Per-client IT documentation, passwords, procedures, and asset records — the agent works from your Hudu content and shows the source on every ticket |
| **IT Glue** | Per-client documentation, configurations, passwords, and flexible assets — the agent works from your IT Glue content and shows the source on every ticket |
| **Confluence** | Your team's shared runbooks and how-tos across all clients — the agent works from your Confluence pages and shows the source on every ticket |
See [Documentation](/dashboard/documentation) for how the agent uses these sources together.
### CRM & business
| Integration | Description |
| - | - |
| **HubSpot** | CRM for managing contacts, deals, and pipelines |
| **Pax8** | Cloud marketplace for licensing and subscription management |
| **PandaDoc** | Document automation and e-signature |
| **KnowBe4** | Security awareness training and phishing simulation |
### Communication
| Integration | Description |
| - | - |
| **Slack** | Team messaging and employee-facing bot channel |
### Scheduling
| Integration | Description |
| - | - |
| **TimeZest** | Send customers a scheduling link automatically when a ticket needs a booked appointment |
Don't see an integration you need? You can connect any tool that implements the Model Context Protocol via [MCP Servers](/integrations/mcp-servers).
# Pax8
Source: https://docs.rallied.ai/integrations/pax8
Answer licensing and pricing questions across every customer from inside a ticket, and let the agent add seats or place Pax8 orders once a tech approves.
Connect Pax8 and your technicians stop bouncing between Pax8 tabs to answer routine licensing questions. Ask **"how many Business Standard seats does Acme have left?"** or **"what does another Defender for Business license cost?"** right on a ticket and the agent has the answer. When a customer needs more seats or a new SKU, the agent lines up the change and waits for a technician to approve before anything gets bought.
Pax8 is configured in **Settings → Integrations**.
## What you get
* **Licensing lookups from inside a ticket.** No more opening Pax8 to check seat counts, subscription status, or what a customer already owns.
* **Instant pricing.** Quote a new SKU or an extra seat without hunting through the catalog.
* **Seat changes and new orders without leaving the ticket.** The agent drafts the change; a technician approves.
* **Nothing gets bought without your sign-off.** Orders and seat updates are held for approval by default.
## How to connect
Sign in to the Pax8 portal as an administrator. Go to **Settings → Integrations** and create a new API credential pair. Copy the **Client ID** and **Client Secret**. The secret is only shown once.
In Rallied, go to **Settings → Integrations**.
Find the Pax8 card and click **Connect**. A credentials form appears.
Fill in:
* **Client ID** — from your Pax8 API credential
* **Client Secret** — from your Pax8 API credential
Click **Save**. Rallied validates the credentials and the card shows **Connected** when complete.
## What the agent can do
**Look things up (runs automatically)**
* Find a customer and pull their details.
* List a customer's subscriptions and drill into any one of them.
* Search the Pax8 catalog for a product, get its pricing tiers, and check any prerequisite SKUs.
* Check provisioning status on a subscription and pull a customer's recent order history.
**Make changes (needs approval)**
* Update an existing subscription — most commonly, adjust seat quantity.
* Place a new order for a product a customer doesn't already own.
## Approval settings
Purchases and seat changes default to **Needs approval**. A technician sees exactly what the agent is about to buy or change and clicks approve or deny. Read-only lookups run automatically.
Flip any of these from the Pax8 detail page once you've watched a few go through and want the agent moving faster on low-risk changes. See [Approval settings](/dashboard/policies) for an overview.
# Rallied Tools
Source: https://docs.rallied.ai/integrations/rallied-tools
A starter toolkit with no accounts to wire up: send email from your own sender address, check site uptime, and look up DNS, SPF, DKIM, and SSL certificates.
Rallied Tools is a small set of first-party tools that ship with every workspace and don't require an external account. It's on for every MSP by default; you only visit it if you want to change the sender your emails go out from, or if you disconnected it and want to turn it back on.
These tools live here today:
* **Send an email** — the agent sends real email from your own address (e.g. `support@yourmsp.com`) when it needs to reach someone outside the ticket thread.
* **Check if a site or server is up** — the agent tests whether a public URL or `host:port` is responding, to confirm an outage or verify that a fix landed.
* **Domain lookups** — the agent reads a domain's public DNS records, email authentication (SPF, DKIM, DMARC), TLS certificate, and registration. See [Domain lookups](#domain-lookups).
## When to use "Send an email"
Use this for out-of-band communication the ticket channel can't cover:
* Notifying an end user by email when their PSA contact doesn't reply through the ticket.
* Alerting a technician or manager during an incident (e.g. "we've contained a compromised account").
* Operational notices — maintenance windows, follow-ups, confirmations.
Ticket replies still go through your PSA. This is for the moments when email is the right channel and there's no ticket to reply to.
Never use this to send passwords or secrets. If the agent needs to share a credential, it uses [Onetime Secret](/integrations/onetime-secret) instead — the recipient gets a one-time link that self-destructs on view.
### How it looks to the recipient
The email arrives from the address you configured (or the Rallied platform sender if you haven't configured one yet), with any Reply-To you set. The recipient sees a normal email, with nothing about Rallied in the "from" line unless you put it there.
Each send is capped at 10 recipients across To, CC, and BCC. If the agent needs to reach more people than that, split them across sends or use the ticket channel.
## Configure your sender address
Until you set your own sender, the agent sends from a generic Rallied address. Point it at your own domain so emails look like they come from your MSP.
In Rallied, go to **Settings → Integrations**, open **Rallied Tools**, find **Send an email**, and open its settings.
* **From address** — the address your emails send from (e.g. `support@yourmsp.com`). Must be on a domain you control.
* **From name** — the display name that shows next to the address (e.g. `Acme IT Support`). Optional.
* **Reply-To address** — where replies land if it's not the same as the From address (e.g. `helpdesk@yourmsp.com`). Optional.
When you save, Rallied registers the sender's domain with our email provider and shows the DNS records you need to add: SPF, DKIM, and (if applicable) DMARC entries. Copy each one into your DNS host.
The dialog stays open on save on purpose: the DNS records are the next thing you need.
Once the records have propagated, click **Verify** in the same dialog. The status flips from `pending` to `verified` when your DNS provider has published the records and our email provider can see them.
Sends from an unverified domain fail with a clear error. The agent won't silently fall back to a different sender.
Only the sender **address** is locked to what you configure. The From **name** can still be overridden per email (e.g. so a workflow can send as "Acme Onboarding" for onboarding notes and "Acme IT Support" for everything else).
## Domain lookups
Four read-only tools answer the common "website or email stopped working" questions from public sources. They need no credentials.
| Tool | What it checks | Use it for |
| - | - | - |
| **Look up DNS records** | A, AAAA, MX, TXT, CNAME, NS, SOA, CAA, or SRV records, from Cloudflare (1.1.1.1) and Google (8.8.8.8) public resolvers | A site or service broke after a DNS or hosting change, or a vendor asked for a TXT or CNAME record |
| **Check email authentication** | MX, SPF (including the 10-DNS-lookup limit), DMARC policy, and DKIM keys, with plain-language findings | Mail going to spam, bounces that mention SPF, DKIM, or DMARC, spoofing reports, or a mail-provider change |
| **Check a site's SSL certificate** | Issuer, covered names, validity dates, days until expiry, and whether the chain is trusted | Certificate-expiry notices, "your connection is not private" warnings, or confirming a renewal is live |
| **Look up domain registration** | Registrar, status, created, updated, and expiry dates, name servers, and DNSSEC, through RDAP (the successor to WHOIS) | Site and email both down because a domain expired or is on hold, renewal notices, or finding the registrar |
A technician might ask on a ticket:
```text theme={"system"}
Acme says their emails are landing in spam since they moved to Microsoft 365. Check acme.com.
```
The agent runs the email authentication check and reports what's wrong, for example a missing DKIM key or an SPF record over the lookup limit.
Keep these limits in mind:
* **Public data only.** DNS lookups can't see a client's internal or split-horizon DNS. The certificate check refuses internal addresses.
* **DKIM needs a selector.** The agent checks the selectors it finds in a message's `DKIM-Signature` header (`s=`). Without one, it tries `selector1`, `selector2`, `google`, `default`, and `k1`.
* **Certificate ports.** The certificate check connects on port 443, 8443, 465, 993, or 995 (HTTPS, alternate HTTPS, SMTPS, IMAPS, and POP3S).
* **Some registries don't publish RDAP.** A few country-code domains return no registration data or no expiry date.
* **Technicians only.** Technicians, the admin [Chat](/dashboard/chat), and automated runs can use these tools. End users can't.
## Approval settings
* **Send an email** defaults to **Needs approval** on customer-facing sends. Public content (anything customer-visible) is blocked in Plan mode and only sends after a technician approves the exact body, the same as PSA replies.
* **Check if a site or server is up** defaults to **Auto-approve** — it's a read-only reachability check.
* **Domain lookups** default to **Auto-approve**. They only read public data.
Flip any of them to Auto-approve or Disabled from the same **Rallied Tools** detail page.
## Disconnecting
Rallied Tools is auto-provisioned on every MSP. If you don't want the agent using it at all:
1. Go to **Settings → Integrations**.
2. Find **Rallied Tools** and click **Disconnect**.
Once disconnected, the agent stops sending email and stops using the reachability check and domain lookups. Auto-provisioning won't turn it back on. Reconnect from the same page whenever you want it back.
## "Send an email" vs. Microsoft 365 "send mail"
These two do different things and both have their place:
* **Rallied Tools "Send an email"** sends from **your MSP's** address, through Rallied's platform email provider. Use it for MSP-branded outreach that isn't tied to a specific customer tenant.
* [Microsoft 365 "Send mail"](/integrations/microsoft-365) sends from a **mailbox in the customer's tenant** via Microsoft Graph. Use it when the message needs to come from the customer's own domain (e.g. HR notifying their staff), or as part of a security-response workflow inside that tenant.
## See also
* [Approval settings](/dashboard/policies) — set Auto-approve / Needs approval for each tool
* [Onetime Secret](/integrations/onetime-secret) — the right way to share passwords or secrets
* [Microsoft 365](/integrations/microsoft-365) — send mail from a customer tenant's mailbox
# Sophos Central: check firewalls and alerts from tickets
Source: https://docs.rallied.ai/integrations/sophos-central
Connect your Sophos Central partner account so the agent can check customer firewalls, find which customer an alert belongs to, and read open Sophos alerts.
Connect your Sophos Central partner account and the agent can work Sophos alerts without a technician opening the Sophos console. When a **"firewall lost connection"** alert arrives, the agent finds the customer, checks whether the firewall is connected again, and reads the alerts Sophos Central still holds. The integration is read-only. Rallied never changes anything in Sophos Central.
Sophos Central is configured in **Settings → Integrations**.
## What you get
* **Firewall status on the ticket.** The agent checks whether a customer's Sophos firewall is connected to Sophos Central right now, along with its model, firmware, and HA cluster state.
* **Alert lookups.** The agent lists a customer's open Sophos alerts and filters them by product, category, severity, or time.
* **Customer lookups from an alert.** The agent finds which customer a firewall belongs to from the name, hostname, or serial number in an alert email.
## Prerequisites
* A **Sophos Central Partner** account. Rallied rejects credentials created in a single customer's Sophos Central dashboard, because they can't see your other customers.
## How to connect
Sign in to Sophos Central Partner. Open **Settings → API Credentials Management** and click **Add Credential**. Choose the **Service Principal Read-Only** role. Copy the **Client ID** and **Client Secret**. Sophos shows the secret only once.
In Rallied, go to **Settings → Integrations**.
Find the Sophos Central card and click **Connect**. Fill in:
* **Client ID**: from your Sophos API credential
* **Client Secret**: from your Sophos API credential
Click **Save**. Rallied validates the credential, confirms it's a partner-level credential, and syncs your customer tenants. The card shows **Connected** when it's ready.
If you no longer have the secret, create a new credential in Sophos Central Partner and reconnect.
## Mapping tenants to clients
When you connect, Rallied syncs the customer tenants in your partner account. Review how each tenant maps to a Rallied client on the **Sophos Central tenants** tab of the integration's detail page. Click **Sync tenants** to pick up customers you've added since.
On a client's ticket, the agent only reads that client's tenant. It fills in the tenant ID by itself.
Searching across every tenant is limited to the MSP admin [Chat](/dashboard/chat) and tickets on your PSA's catch-all client. That's where alerts for an unknown customer usually land. End users can't run any Sophos Central tool.
## How the agent uses it
A typical "gateway down" alert arrives on the catch-all client with only a firewall name. The agent:
1. Finds the firewall's customer by searching each tenant's firewalls for the name, hostname, or serial number. If the alert names the customer, the agent searches only matching tenants, which is much faster.
2. Checks whether the firewall is connected to Sophos Central now.
3. Lists the customer's alerts to see whether Sophos Central still holds the alert. An alert that's no longer listed has most likely been cleared or acknowledged.
On large partner accounts, a firewall search covers up to 30 tenants per call and continues where it left off. The agent doesn't report "not found" until it has searched every tenant.
## Tools
| Tool | Default policy | Description |
| - | - | - |
| `sophos_central:sophos-list-tenants` | Auto | List the customer tenants in your partner account (admin chat or catch-all client only) |
| `sophos_central:sophos-find-tenant` | Auto | Find a customer tenant by name or part of a name (admin chat or catch-all client only) |
| `sophos_central:sophos-find-firewall` | Auto | Find which customer a firewall belongs to by name, hostname, or serial number (admin chat or catch-all client only) |
| `sophos_central:sophos-list-firewalls` | Auto | List a customer's firewalls and whether each is connected now |
| `sophos_central:sophos-list-alerts` | Auto | List a customer's open alerts, filtered by product, category, severity, or time |
| `sophos_central:sophos-get-alert` | Auto | Get one alert by ID |
## Policies
Per-tool policies are configured on the **Sophos Central** integration detail page (open it from **Settings → Integrations**).
See [Approval settings](/dashboard/policies) for an overview.
# SuperOps
Source: https://docs.rallied.ai/integrations/superops
Have the agent work SuperOps tickets end-to-end and take action on managed endpoints, all from the same conversation your technicians already use.
Plug Rallied into SuperOps and Rallied's agents pick up new tickets the moment they land, gather the context your technicians would normally have to chase down, and either resolve the ticket or hand it back with a clear plan and a recommendation. Your team stops doing the tedious first pass on every ticket and gets to focus on the ones that actually need a human.
A few concrete wins after you connect:
* **Tickets get worked at any hour.** Rallied starts diagnosing the second a ticket is created in SuperOps — no waiting for someone to grab it from the queue.
* **Less reading, less swivel-chairing.** The agent reads the ticket, looks up the requester, pulls relevant context from your other connected tools, and posts an internal note with everything your tech would have written up by hand.
* **Routine work resolves itself.** Password resets, license assignments, group membership changes, account unlocks, common how-do-I requests — the agent handles them end to end on the tickets you allow it to.
* **Your tech approves, never writes.** When the agent wants to make a change, it writes the plan as an internal note on the SuperOps ticket. Your tech clicks approve or deny without leaving SuperOps.
* **Nothing happens you didn't sign off on.** You decide which actions Rallied can take on its own and which need a human approval per ticket.
SuperOps is configured in **Settings → Integrations**.
## Connect SuperOps
You'll need an API token and your tenant's subdomain.
Sign in to SuperOps and go to **Settings → My Profile → API Token**. Generate a token and copy it — it's only shown once.
Notes and replies the agent posts in SuperOps show up under the name of the user this token belongs to. Most MSPs create a dedicated user like **Rallied** (or `rallied@yourmsp`) so it's obvious in the ticket history which work was done by your agents vs. your team.
Open **Settings → MSP Information**. Your subdomain is the part before `.superops.ai` — for example, in `acme.superops.ai` the subdomain is `acme`.
In Rallied, go to **Settings → Integrations**, find the SuperOps card, and click **Connect**. Paste the subdomain and the API token, then click **Save**.
You don't need to tell Rallied which region you're in. On save, it checks both the US and EU SuperOps regions and connects to whichever one your tenant lives in.
Choose which SuperOps clients you want Rallied's agents to handle tickets for. You can start with one client to evaluate, then expand from there.
You don't need to set up the webhook in SuperOps. Rallied wires that up for you so new tickets, ticket updates, and customer replies are picked up automatically. Every event is verified two ways before an agent sees it — a cryptographic signature proving it really came from SuperOps, plus a token unique to your MSP — so nobody can spoof tickets into your agents.
If you later disconnect SuperOps, Rallied removes the webhook subscription from your tenant so events stop flowing. The clients you imported stay in Rallied.
## What happens when a ticket comes in
The moment someone opens a ticket in SuperOps for one of the clients you've enabled, the agent gets to work:
1. **Reads the full ticket and conversation thread** so it has the same context your tech would.
2. **Identifies the requester** and looks them up in your connected identity provider (e.g. Microsoft 365) — so password resets, group changes, and access requests all hit the right account.
3. **Posts an internal note explaining what it understood and what it plans to do.** Your tech can read this at any time without having to ping the agent.
4. **Either does the work, or asks for approval first** — depending on the rules you set.
5. **Closes the loop.** Once it's done, it posts a final internal note with what it did. By default it doesn't message the requester directly — your tech can do that, or you can tell the agent to.
If you've connected an identity verification provider like [Traceless](/integrations/traceless), the agent will challenge the requester for an MFA push before doing anything sensitive (password resets, MFA changes, admin permission grants). The agent waits for the result and posts the outcome on the ticket — your tech can see exactly whether the requester confirmed it was really them.
## Approving an action without leaving SuperOps
For anything the agent isn't allowed to do on its own, it stops and posts an internal note on the ticket explaining what it wants to do, with one-click **Approve** and **Deny** links right in the note. Your tech responds in SuperOps — no separate tool, no extra inbox.
Only the technician assigned to the ticket can approve. Replies from anyone else are treated as regular comments and don't move the approval forward.
## Internal notes vs. customer replies
The agent has two ways to communicate on a SuperOps ticket, and the defaults are conservative:
* **Internal notes** — private to your team. The agent uses these by default for everything: its reasoning, what it did, what went wrong, approval requests. Your customers never see them.
* **Customer-visible replies** — visible to the requester and emailed to them. The agent only sends these when you've explicitly told it to (in the client's prompt or a workflow). Otherwise it stays internal and your tech handles the customer-facing comms. In Plan Mode, customer-visible replies are always blocked — even for clients where you've enabled them.
The agent can write its notes in Markdown or HTML; either way they show up as properly formatted HTML in SuperOps.
This means you can roll Rallied out without worrying about it messaging your customers in a tone or style you haven't approved.
## What needs approval
You control which actions the agent takes on its own and which need a sign-off, on the SuperOps page under **Settings → Integrations**. The defaults are designed so the agent can read freely and write internal notes without bothering anyone, but anything that changes ticket state or talks to a customer needs you to approve:
* **Auto-approve** — reading tickets, conversations, notes, statuses, priorities, categories, technicians, clients, and contacts. Posting internal notes.
* **Needs approval** — updating tickets (status, priority, technician, etc.), triaging tickets, and posting customer-visible replies.
For anything the typed actions above don't cover, the agent also has a general-purpose fallback against the SuperOps API: read-only queries (`superops-gql-query`) run automatically, and anything that changes data (`superops-gql-mutate`) always needs approval.
See [Approval settings](/dashboard/policies) for the bigger picture.
## Tell the agent how to handle your most common tickets
If you've got a kind of ticket you see all the time — new-hire onboarding, password resets, **"can I get added to the shared mailbox"** — write a [workflow](/dashboard/workflows) and the agent will handle that ticket type the same way every time, in line with how your senior techs do it.
## Try it out
Create a ticket against one of the clients you enabled, with a short subject and description.
In Rallied, open **Activity** (or the client's page). The new ticket should appear within seconds with the agent already at work. In Plan Mode you'll see an internal note describing what the agent would do; in Execute Mode you'll see it taking the actions you've approved.
If the ticket doesn't show up in Rallied, double-check:
* Your subdomain matches your SuperOps URL exactly.
* The API token hasn't been rotated in SuperOps since you connected.
* The test ticket is on a client you enabled when connecting.
# TimeZest
Source: https://docs.rallied.ai/integrations/timezest
End the scheduling back-and-forth: the agent drops a TimeZest self-service booking link into any ConnectWise or Autotask ticket that needs an appointment.
Connect TimeZest so the agent sends customers a scheduling link the moment a ticket needs a booked appointment. Instead of a dispatcher watching the queue for tickets that need scheduling and manually firing the TimeZest request, the agent picks that up automatically — remote or on-site, right appointment type, right technician — and lets TimeZest close the loop back on the ticket.
TimeZest is configured in **Settings → Integrations**. Works with ConnectWise and Autotask tickets today; HaloPSA support is planned.
## What it's for
If you already run TimeZest with ConnectWise or Autotask, the current workflow is:
1. A ticket comes in that needs a booking.
2. A dispatcher moves it to the scheduling status.
3. TimeZest sends the customer a link.
4. The customer books, and TimeZest writes the appointment back on the ticket.
With Rallied connected, the agent replaces the dispatcher step. Tickets that need scheduling get their link sent right away, without your dispatcher having to babysit the queue. TimeZest still owns the booking and the write-back onto the ticket — nothing about how appointments show up in your PSA changes.
The result: more of your tickets go through TimeZest, faster, without adding to your dispatcher's plate.
## How to connect
Sign in to TimeZest and go to **Settings → API Keys** ([app.timezest.com/settings/api\_keys](https://app.timezest.com/settings/api_keys)). Create a key with **Read/Write** access, give it a recognizable label (e.g. `Rallied Integration`), and copy the key. It's shown only once.
In Rallied, go to **Settings → Integrations**.
Find the TimeZest card and click **Connect**. A credentials form appears.
Fill in:
* **API Key** — the key you generated above.
* **API Base URL** — leave empty. Only fill this in if TimeZest support gave you a custom host.
* **How to deliver the scheduling link** — pick one:
* **TimeZest sends the email to the customer** — TimeZest emails the customer directly, matching how your dispatchers use it today.
* **Return a link for Rallied to post on the ticket** — the agent posts the link as a ticket reply so the customer sees it in the PSA thread instead of a separate email.
After the key is validated, a second step lets you pick — from dropdowns populated with your TimeZest account — which appointment type to use for **remote** vs. **on-site** work.
## How the agent uses TimeZest
The easiest way to turn this on is the **Send TimeZest scheduling link** workflow template on [Workflows](/dashboard/workflows). Enable it and every ticket that reaches your scheduling status will trigger the agent to:
1. Decide whether the work is remote or on-site based on the ticket.
2. Resolve who to book it with from the ticket's assigned technician — Rallied matches the technician's email against your TimeZest agents, so there's nothing to configure up front. If the ticket has no assigned technician, or no TimeZest agent shares that email, the agent won't guess: it posts an internal note explaining what's blocking it instead of booking the wrong person.
3. Send the scheduling link using the delivery mode you chose.
4. Stay out of the way — TimeZest owns writing the booked appointment back onto the ticket.
You can also point custom workflows at TimeZest. Anywhere your instructions say **"send the customer a scheduling link"**, the agent will use TimeZest if it's connected.
Make sure your scheduling status is also enabled under your PSA integration's **Webhook → Ticket Filters** settings — otherwise Rallied won't see tickets that move into that status.
## Approval settings
Sending a scheduling link is customer-facing, so it defaults to **Needs approval**. Flip it to **Auto-approve** from the TimeZest detail page once you've watched a handful of requests go through cleanly and want the agent to send links without waiting for a technician.
Read-only actions (listing appointment types and teams) run automatically.
## Disconnecting
Click **Disconnect** on the TimeZest detail page. The agent stops sending scheduling links. Any bookings TimeZest already made stay on the ticket. Rallied never wrote to them and won't touch them on disconnect.
## See also
* [Workflows](/dashboard/workflows) — turn on the **Send TimeZest scheduling link** template
* [ConnectWise Manage](/integrations/connectwise)
* [Autotask](/integrations/autotask)
# Traceless
Source: https://docs.rallied.ai/integrations/traceless
Confirm callers are who they say they are: Traceless triggers MFA push verification across mixed Duo and Microsoft Authenticator stacks in one call.
Traceless is an identity verification orchestrator. When the agent needs to confirm an employee's identity before a sensitive action, Traceless sends an MFA push notification through the employee's existing authenticator (Duo or Microsoft Authenticator), so you don't have to connect each one individually.
Traceless is configured in **Settings → Integrations**.
## When to use Traceless
Use Traceless if you want a single identity verification provider that works across an end-user base with mixed MFA tools. Traceless routes each push to the user's existing factor, so you don't need to connect Duo and Microsoft 365 separately just for verification.
If all your clients use the same provider (for example, Microsoft 365 everywhere), you can use that provider's native push directly — see [Identity verification](/agents/identity-verification).
## How to connect
You'll need API credentials from your Traceless admin settings before starting.
Sign in to [Traceless](https://traceless.io/settings/) as an organization admin. From the admin settings page, copy your **API signing secret** and **Organization UUID**.
In Rallied, go to **Settings → Integrations**.
Find the Traceless card and click **Connect**. A credentials form appears.
Fill in:
* **API Signing Secret** — the signing secret from Traceless admin settings.
* **Organization UUID** — your Traceless organization identifier.
* **Default Push Method** — the authenticator app to route pushes to: **Microsoft Authenticator** or **Duo Push**.
Click **Save**. Rallied validates the credentials against the Traceless API. The card shows **Connected** when complete.
## How verification works
When the agent decides an action is sensitive — for example, a password reset or admin permission change — it asks Traceless to verify the requesting employee:
The agent asks Traceless to challenge the employee using their work email. Traceless finds the right device against your connected MFA system.
The employee gets a push notification on the configured authenticator app and approves it from their phone.
The backend polls Traceless every few seconds for up to 5 minutes until the verification resolves.
On **approval**, the agent continues the plan. On **denial**, **timeout**, or **failure**, the agent stops and informs the requester.
## Turn off requester verification
Traceless has two jobs. It verifies requesters before the agent acts on sensitive tickets. It also delivers credentials to employees through one-time secret links. You can turn off verification and keep Traceless for secret links only.
The **Verify requester identity** switch is on the **Traceless** integration detail page (open it from **Settings → Integrations**). It's on by default. You need integration write access to change it.
| Setting | What happens on a sensitive ticket |
| - | - |
| **On** (default) | Traceless sends the requester a verification push. The agent does not act until the requester approves it. |
| **Off** | Traceless sends no verification push. The agent plans the work, and a technician must approve the plan before anything runs. The plan states that the requester's identity was not verified. |
Secret links still go through Traceless when verification is off.
When verification is off, your technician's plan approval is the only check on sensitive requests like password and MFA resets. Review who requested the change before you approve the plan.
## Push method options
| Method | Authenticator app |
| - | - |
| **Microsoft Authenticator** | Microsoft Authenticator on iOS or Android |
| **Duo Push** | Duo Mobile |
The push method you select applies to every verification Traceless handles for your MSP. To change it later, reconnect Traceless with the new value.
## Outcome notes on tickets
When verification is triggered from a PSA ticket — for example, a new ConnectWise service ticket flagged as sensitive — Rallied posts an internal note on the ticket as soon as the verification resolves so your technicians always see the outcome:
* **Approved** — the agent is now processing the ticket.
* **Denied or failed** — the agent will not process the ticket; it needs human handling.
* **Expired** — the requester did not respond within the timeout window; the agent will not process the ticket.
## Limits and timing
* The verification window is **5 minutes** from the moment the push is sent. After that, the verification expires and the agent does not execute the action.
* The agent's tool execution is paused for the entire client session while a verification is pending. No further actions run until the verification resolves.
* A fresh verification is required for every new sensitive request, even from the same employee.
If verification fails or expires, the agent never executes the sensitive action — even if a technician already approved the plan. The requester must resubmit to try again.
# Quick Start
Source: https://docs.rallied.ai/quickstart
Set up Rallied from scratch: connect your PSA, Microsoft 365, and documentation platform, then add your first client and get the agent answering tickets.
This guide walks you through setting up Rallied from scratch. You'll connect the three MSP-wide integrations the agent needs to work (your PSA, Microsoft 365, and your documentation platform), then add your first client and get the agent answering tickets in your PSA.
Go to [app.rallied.ai](https://app.rallied.ai) and sign in with your MSP account credentials.
You'll land on the Clients list, your home base for managing all the companies you provide IT services for.
The PSA is where employees submit tickets, where the agent posts its work, and where your technicians approve sensitive actions.
Connecting your PSA for the first time starts your 14-day free trial, with 2,000 credits and no card required. Add a card on **Settings → Billing** at any time to convert. See [Credits & Billing](/billing/credits).
Go to **Settings → Integrations** and click **Connect** next to your PSA. After the connection succeeds, a setup wizard opens automatically and walks you through the remaining configuration.
The wizard is mandatory on first connect. You cannot close it until the required steps are done. If you leave the page, the wizard resumes automatically when you return.
**ConnectWise Manage** runs a four-step wizard:
1. **Import company types**: choose which ConnectWise company types become Rallied clients. Pick at least one or the agent has no clients to work.
2. **Service boards**: select the ConnectWise service boards the agent can see tickets on. Without a board in scope, the ticket workspace and the agent see nothing.
3. **Ticket statuses**: pick which ticket statuses the agent acts on, per board. The agent won't work tickets in statuses you haven't selected.
4. **Map members** (optional): map Rallied users to their ConnectWise members so ticket updates and time entries are attributed correctly. You can skip this and set it later from the configuration tab.
**HaloPSA** and **Autotask** open a single step after connect: select which company types or clients to import into Rallied.
Once the wizard finishes, the agent receives new tickets via webhook, posts internal notes documenting its reasoning, and routes approval requests as ticket comments.
Microsoft 365 is the agent's primary identity backbone. Connecting it lets the agent look up users, reset passwords, manage group membership, and handle Teams or Intune actions across every client tenant via GDAP.
In **Settings → Integrations**, click **Connect** on **Microsoft 365** and complete the multi-tenant app registration flow with your partner tenant admin account. See the [Microsoft 365 setup guide](/integrations/microsoft-365) for app registration details and the GDAP role mappings.
Hook up the platform where your team stores client-specific knowledge (passwords, runbooks, procedures, asset records). The agent reads from it during diagnosis so it can answer questions the same way your senior technicians would.
| Integration | What the agent reads |
| - | - |
| **Hudu** | Articles, passwords, SOPs, assets |
| **IT Glue** | Documents, passwords, configurations, flexible assets |
In **Settings → Integrations**, click **Connect** on Hudu or IT Glue and enter your API key.
Back on the **Clients** list, click **Create Client** in the top right.
Fill in:
* **Name** — the company name as you want it to appear in Rallied (e.g., "Acme Corp")
* **Slug** — a short identifier used internally (e.g., `acme-corp`). Lowercase letters, numbers, and hyphens only.
Click **Create**. The agent provisions automatically. Status moves from `pending` → `provisioning` → `active` within a minute or two.
On the new client's **Integrations** tab, map it to the matching company record in your PSA, the matching Microsoft 365 tenant, and the matching documentation site. This tells the agent which records belong to this client so it can scope its tool calls correctly.
Open the client's **Integrations** tab and click into a connected integration to see every action the agent can take, along with its current policy.
![Per-tool permissions on an integration's detail page]()
Review the defaults and adjust where needed:
* Set read-only actions (like "get user" or "list articles") to **Auto** so the agent runs them freely.
* Set write actions (like "reset password" or "add user to group") to **Approval needed** until you trust the agent's judgment.
* Set any actions you don't want the agent to use to **Disabled**.
Rallied pre-classifies actions by name: read-like verbs default to **Auto-approve**, write-like verbs default to **Needs approval**. You're adjusting from a reasonable starting point, not configuring from scratch.
Go to the **Overview** tab for the client. Under **Operating Mode**, choose how the agent should behave:
* **Plan Mode** — the agent reads, diagnoses, and posts a private internal note with its plan. It never executes actions or replies to the employee. Use this to verify the agent understands your environment correctly.
* **Execute Mode** — the agent executes requests. Auto-approved actions run immediately; actions that need approval pause and wait for your team to approve before proceeding.
* **Inherit** — the client uses whatever mode you've set at the MSP level.
Plan Mode is strongly recommended for initial setup. Run a few real requests through it, review the internal notes, and confirm the agent is reasoning correctly before switching to Execute Mode.
Wait until the client status shows **active**. The agent is now live and listening on your PSA.
Open your PSA and create a new ticket against the test client:
> "My account is locked out"
In Plan Mode, the agent posts an internal note on the ticket describing exactly what it would do: which tools it would call, in what order, and the expected outcome. No action runs.
In Execute Mode, the agent works through the request, verifying the user in Microsoft 365, checking your docs platform for a relevant runbook, and either executing the unlock or requesting approval based on the policies you set.
Every action the agent took or attempted appears in the client's **Activity** tab.
## Setup banner
If an integration's required configuration is missing or breaks after it was working, an amber banner appears at the top of the integration's detail page:
> **Setup isn't finished — the integration won't work until you complete it.**
Click **Continue setup** to reopen the wizard and finish (or re-fix) the required steps. You can also click **Exit setup** to close the wizard and return to the page. The banner stays until the integration is fully operational again.
The banner shows when any of these happen:
* A required step was never completed (fresh install)
* A previously completed step regressed (for example, the intake routing PSA was disabled)
* A per-client provisioning step is still pending (for example, Teams is waiting for the first client tenant to be linked and consented)
* A post-setup guided tour hasn't been seen yet (for integrations that have one)
Read-only users see the banner with a disabled button, so they know setup is needed even though they can't run it.
## What's next
* **Prompt customization** — add client-specific context in the **Prompt** tab (what apps they use, any special handling rules) for more accurate responses.
* **More integrations** — connect your RMM, security tools, identity provider, and more from the [integrations catalog](/integrations/overview).
* **Workflows** — set up [workflows](/dashboard/workflows) for your most common ticket types so the agent handles them exactly the way you want, every time.
* **Credits**: see what each ticket costs and track your balance on **Settings → Usage**. See [Credits & Billing](/billing/credits).
* **API** — create a token and call the [Rallied API](/api/talk) to ask the agent about a ticket from your own tools.
# Security and trust at Rallied
Source: https://docs.rallied.ai/security
Give an AI real access without losing sleep: platform-enforced approval rules, per-client isolation, MFA on sensitive work, and a full audit trail.
Giving an AI write access to your PSA and your clients' Microsoft 365 tenants should make you nervous. This page explains how Rallied keeps that access safe: the guardrails the platform enforces on every agent action, how credentials and data are isolated between clients, and what your team can audit after the fact.
The short version: LLMs aren't deterministic. Ask one the same question twice and you can get two different answers. At scale, hoping the model behaves consistently isn't a plan, so we didn't build on hope. Deterministic rules live in our platform, where the agent can't touch them.
## Rallied enforces the rules
Every action the agent can take has a setting: auto-approve, needs approval, or disabled. The platform enforces these, so the agent can't talk its way past a setting by rewording the request or reaching for a different tool.
This is the part most homegrown agents get wrong. Their guardrails live in the prompt, and a prompt is a polite request. The model can drift from it, and a cleverly worded request can talk it out of it.
## Write actions need approval by default
When you connect an integration, by default reads are automatic and writes require a human in the loop.
If you want to see how the agent thinks before giving it any power, run a new client in Plan mode. The agent works real tickets with read-only tools and posts what it would have done as an internal note. Once you trust its judgment, you let it act. We recommend this for every new client.
## Plans are tightly scoped
An approval isn't a blank check. Before anything runs, Rallied compares the action against the plan the agent showed you, value by value, and refuses it if a single value is different. The agent has to come back and request a fresh set of approvals.
## Bad actor detection
The oldest helpdesk scam is pretending to be someone else: call in, say you're an employee, ask for a password reset. So when a request touches credentials, admin rights, or permissions, the agent assumes it's talking to an impostor until the employee proves otherwise.
Proof is an MFA push to the actual employee through Duo, Traceless, or Microsoft Authenticator. The platform decides which requests are sensitive, and when it can't tell, it errs on the side of caution. If the push fails or times out, nothing runs, no matter what else was approved. While a check is open the agent can only post notes, and if the employee has no enrolled device, it hands the ticket to a person with a note on what happened.
## Credential storage
Your integration credentials are stored encrypted, and the agent never has access to them. When it uses a tool, the platform makes the API call and hands back just the result. Disconnecting an integration or deleting a client revokes the credentials.
Passwords get the same treatment. The agent can find one by name but can't search by value, and end users never see one in a ticket. If you want password text out of tickets entirely, turn on single-use links that destroy themselves after one view.
## Client separation
Every client gets its own agent, running in its own container, and it sees only that client's users, tickets, and runbooks.
Some credentials cover many clients, like Microsoft 365. There, every call names the client it's for, and the platform checks that name against the agent making the call. If the name is missing, unknown, or wrong, the call is refused.
## Audit logs
Everything the agent does is logged: every tool call, approval, and conversation. Refused actions are logged too, with the reason.
## SOC 2 Type II
An external auditor verifies our SOC 2 Type II controls. The latest audit period ended in July 2026, and the report is being finalized now. Our [trust center](https://trust.rallied.ai/) has the control list and our subprocessors, monitored continuously through Vanta.
## Build vs buy
You could build all of this yourself. A demo agent is a weekend project, which is exactly what makes it misleading, because the demo is the easy part. The policy engine, the approval workflow, the MFA checks, the credential store, the client isolation, the audit log: that work is the year after the weekend, and then someone on your team maintains it through every API change, forever.
The case for buying isn't that our agent is smarter than one you could wire up. It's that the controls around it already exist, and are on from your first ticket. They don't loosen as you grow, and you're live in days instead of months.
## Related pages
* [Plan mode](/agents/plan-mode)
* [Approval settings](/dashboard/policies)
* [Identity verification](/agents/identity-verification)
* [Activity and audit logs](/dashboard/activity)