> ## Documentation Index > Fetch the complete documentation index at: https://explore.airia.com/llms.txt > Use this file to discover all available pages before exploring further. # Actions > Add prebuilt integration steps to an agent so it can read and write data in third party applications like Salesforce, Slack, Gmail, and Stripe. Actions are prebuilt workflow steps that connect an agent to a third party application. Each action performs one operation against a vendor API, such as creating a Salesforce lead, posting a Slack message, sending an email through Gmail, or charging a customer in Stripe. You add an action to the canvas, point it at a credential, fill in its inputs, and connect it to the rest of your flow. Actions let an agent do more than reason about information. They let it act on that information inside the systems your team already uses. **Actions and Tools are different things.** A [Tool](/integrations/Tools/tools) is attached to a model so the model can decide when to call it during a conversation. An Action is a deterministic step in your workflow that runs in the order you wire it, with inputs you control. Use an Action when you want a specific operation to happen at a specific point in the flow. Use a Tool when you want the model to choose. ## How actions work Every action is one step that maps to a single vendor operation. When the step runs, it authenticates with the credential you selected, sends the request to the vendor, and returns the response as step output that later steps can read. Actions are organized in the builder by vendor. Open the **Actions** panel in the step sidebar, choose a vendor such as Asana or Stripe, and you will see that vendor's operations grouped by the object they act on. Stripe, for example, groups its actions under **Balance**, **Charge**, and **Customer**. Drag the operation you want onto the canvas and it becomes a configurable step. On the agent canvas, open the step sidebar and select **Actions**. Pick the vendor you want to work with. Drag an operation, for example **Slack Message Post**, onto the canvas. It appears as a step with input fields in the right side panel. Choose the credential the step will authenticate with. The dropdown only lists credentials of the type that vendor accepts. See [Authentication](#authentication) below. Enter a fixed value for each input, or map it to the output of an earlier step. See [Configuring inputs](#configuring-inputs). Wire the step into your flow, then run the agent to test it. The step output is available to every step downstream. ## Supported integrations Airia ships actions for the vendors below. Open a vendor page for the full list of operations, their inputs, and usage guidance. Leads, accounts, contacts, and opportunities. Companies, contacts, and deals. Account records in Dataverse. Tasks, subtasks, comments, projects, and tags. Issues across teams and projects. Pages, databases, and search. Messages, drafts, threads, and labels. Messages, drafts, folders, and attachments. Messages, channels, reactions, and users. Contacts and conversations. Transactional email and contacts. Calendar events. Files and folders. Meetings and users. Tickets, users, and organizations. Charges, customers, and balance. User lifecycle management. S/4HANA business partners, materials, and orders. ## Prerequisites Before you can use a vendor's actions, a credential must exist for that vendor. Every action authenticates with a stored credential. Create the credential once in [Credential Management](/admin-hub/account_settings/credential-management), then select it on any action for that vendor. The credential type depends on the vendor, covered next. ## Authentication Each action authenticates with a credential you select on the step. The builder only shows credentials of the type the vendor accepts, so you cannot accidentally point a Slack step at a Stripe key. Vendors authenticate in one of two ways. OAuth based vendors require an app registration before credentials can be created. The agent acts on behalf of the connected account. | Vendor | Credential type | Setup guide | | ------------------------------------ | ---------------------------------- | -------------------------------------------------------------------------- | | Gmail, Google Calendar, Google Drive | Google OAuth | [Google Cloud Console](/integrations/oauth-setup/google-cloud-console) | | Microsoft Outlook | Microsoft OAuth | [Microsoft Entra](/integrations/oauth-setup/microsoft-entra) | | Dynamics 365 | Dynamics 365 OAuth | [Microsoft Entra](/integrations/oauth-setup/microsoft-entra) | | Salesforce | Salesforce OAuth | [Salesforce](/integrations/oauth-setup/salesforce) | | Notion | Notion OAuth or integration secret | [Credential Management](/admin-hub/account_settings/credential-management) | | Slack | Slack OAuth or bot token | [Credential Management](/admin-hub/account_settings/credential-management) | | Zoom | Zoom OAuth | [Credential Management](/admin-hub/account_settings/credential-management) | These vendors authenticate with a key or token you generate in the vendor's own admin console, then paste into a credential. | Vendor | Credential type | | -------- | --------------------- | | Asana | Asana token | | Stripe | Stripe API key | | SendGrid | SendGrid API key | | HubSpot | HubSpot token | | Intercom | Intercom access token | | Linear | Linear API key | | Zendesk | Zendesk API key | | Okta | Okta API key | | SAP | SAP API key | Some vendors, including the Google services, Microsoft Outlook, Salesforce, and Notion, also support end user authentication. With end user auth the step runs against the credential of the person using the agent rather than a single shared connection, which is useful for agents that act on each user's own mailbox or files. Configure this on the step where the option is available. ## Configuring inputs Each action exposes a set of inputs. Some are required and some are optional, and every vendor page documents them in a table. Inputs accept values in two ways. Type a value directly into the field. Use this when the value never changes, such as a currency code or a channel name. Bind the field to the output of an earlier step. Open the field's dropdown, choose `stepResult`, then pick the source step. The reference highlights in blue when it is valid and resolves to a live value at run time. Most text inputs can be mapped to an earlier step's output. In the input tables on each vendor page, these fields are marked as **dynamic**. A smaller set of inputs, mostly numbers, toggles, and dropdown selections, take a fixed value only and are marked **fixed**. A common pattern is to put a model step before an action and let the model produce the values the action needs. For example, a model can read an incoming support email, decide a priority and a summary, and a Zendesk Ticket Create step downstream maps its **Subject** and **Priority** inputs to that model's output. ## Reading action output When an action runs it returns the vendor's response as step output. Downstream steps reference it with the standard variable syntax, for example a created record's ID or a list of fetched items. Feed that output into a later action, a [filter](/building-and-deploying-agents/agent-basics/filter-step), or a model step that summarizes the result in natural language. For more on referencing step output, see [Agent variables](/building-and-deploying-agents/agent-basics/agent-variables). ## Example workflow A support triage agent that turns inbound email into a tracked ticket and notifies the team: A **Gmail Message Get** action retrieves the unread support email. A model step reads the email body and produces a short subject, a priority, and a one line summary. A **Zendesk Ticket Create** action maps its **Subject**, **Description**, and **Priority** inputs to the model's output, then files the ticket. A **Slack Message Post** action maps its **Text** input to a message that includes the new ticket ID returned by the previous step, and posts it to the support channel. This flow chains three vendors and a model into a single automation, with each step passing its result to the next. ## Troubleshooting The credential either does not exist yet or is not the type the vendor accepts. Create the correct credential in [Credential Management](/admin-hub/account_settings/credential-management), then reopen the step. The credential expired, was revoked, or lacks permission for the operation. Re-authenticate the credential and confirm the connected account can perform the action in the vendor's own application. For end user auth, confirm the running user has connected their account in their user settings. The step will not run until every required input has a value. If you mapped an input to an earlier step, confirm that step actually produced a value and that the reference shows in blue. The source step may not have run, or its output field name changed. Reopen the field, reselect the source step, and run the upstream step once so its output is available.