# App integration nodes

App integration nodes connect a flow to the external systems your process depends on — reading from them, acting on them, and writing results back to them. In Bevaya, integrations are not a separate feature: they are nodes you add to a flow and configure inline, so the system you connect to becomes one more step in the agent.

Two integration families are available today:

- **Outlook** — authorize a mailbox, then download, send, mark, and move email. These nodes pair with the [Outlook Trigger](./triggers.md) to build email-driven processes end to end.
- **Guidewire** — search, create, and update claims in Guidewire ClaimCenter, typically as the write-back step after extraction.

Other app connectors appear in the Nodes library but are **not available** yet; they are listed at the end of this page for visibility only.

## Before you begin

These points apply to every available node on this page.

**Required permissions.** Adding and configuring integration nodes is part of building a flow, so it requires build access to the AI Agent — the **Admin** or **Partner** role. The **Reviewer** role cannot build or configure flows. Storing connection credentials as environment variables also requires Admin or Partner. See [Users and access](../onboarding/users-access.md).

**Store credentials as variables, never in plain text.** Connection details such as client secrets, tenant IDs, and API tokens should be stored as variables in the environment where the flow runs, then referenced from a node's configuration. This keeps secrets out of the flow definition and lets the same flow run against different environments. See [Configure environments and variables](./environments-variables.md).

**Field mapping.** Integration nodes take most of their values from earlier steps rather than from typed-in constants. Where a field accepts a mapped value, you point it at the output of an upstream node — for example, mapping extracted fields into a Guidewire claim, or passing the access token from the authentication node into each Outlook action.

**Output format (HTTP-based nodes).** The Guidewire nodes and the [API Request](./utility-nodes.md) node let you choose how much of the system's response to keep: **Full Response** (status code, headers, and content — the default), **Content Only** (the response body), or **Raw Bytes**. Choose Full Response while building so you can see status codes when troubleshooting.

**Errors and retries.** These nodes make one request per run; there is no per-node automatic retry in the current builder. If a request fails, the step fails and the run is marked failed. Inspect the failed step in [Run history](../monitor-review/run-history.md), fix the cause in the draft, and re-test before publishing a corrected version — see [Test and debug a draft](./test-debug-draft.md). To trigger a rerun programmatically without changing the draft, use the [API rerun endpoint](/api/flow-executions#rerun-a-flow-execution). For write-back steps, guard against duplicates and partial writes using [Control nodes](./control-nodes.md) and [Field Validation](./utility-nodes.md), and route exceptions to a person with [Flag for Human Review](./utility-nodes.md).

---

## Outlook

The Outlook nodes work as a set. **Outlook: Auth** establishes an authorized session and produces an access token; every other Outlook node takes that token (mapped from the auth node's output) plus a mailbox identifier to act on a specific message. Most flows authorize once near the start, then reuse the token across the email actions that follow.

**Shared prerequisites.** A Microsoft 365 mailbox your organization controls, and an application registered in your Microsoft identity provider (Microsoft Entra / Azure AD) that grants Bevaya permission to access that mailbox. Your IT team provides the tenant ID, client ID, and client secret used by **Outlook: Auth**. Store these as variables.

### Outlook: Auth

In the Nodes library this node is labelled **MS Graph Auth**.

**What it does.** Obtains an OAuth access token for the Microsoft identity platform so the other Outlook nodes can act on a mailbox.

**Status:** Available.

**When to use it.** As the first Outlook step in any flow that downloads, sends, marks, or moves email. Run it once and reuse its token downstream.

**Configuration fields**

- **Base URL** — the base URL for the Microsoft identity platform.
- **Tenant ID** — your Microsoft tenant ID.
- **Endpoint Path** — the OAuth token endpoint path. Pre-filled and read-only.
- **HTTP Method** — pre-filled and read-only.
- **Headers** — request headers. Pre-filled for the client-credentials request.
- **Request Body** — the client-credentials values (such as client ID, client secret, and scope). Map these from variables rather than typing secrets directly.

**Inputs.** Connection settings and credentials, supplied from variables.

**Outputs.** An access token representing the authorized session.

**How downstream nodes use the output.** Map the access token into the **Access Token** field of each Outlook action node.

**Set it up**

1. Add **MS Graph Auth** near the start of your flow.
2. Set **Base URL** and **Tenant ID**, and map the client credentials in **Request Body** from variables.
3. Connect it ahead of the Outlook action nodes and map its access token into each one.

**Example.** A submission-intake flow runs **MS Graph Auth** right after the Outlook Trigger, then passes the token to **Download Email** to pull the attachments.

### Download Outlook Email

In the Nodes library this node is labelled **Download Email**.

**What it does.** Downloads an email and its attachments from the connected mailbox.

**Status:** Available.

**When to use it.** Immediately after the Outlook Trigger, to retrieve the message body and attachments for processing.

**Configuration fields**

- **Access Token** — the token from **Outlook: Auth**.
- **Event ID** — the current run identifier, used to associate the downloaded files with this run.
- **Message ID** — the message to download, mapped from the Outlook Trigger.
- **User ID** — the mailbox to read from.

**Inputs.** A message reference from the Outlook Trigger, plus the access token.

**Outputs.** The downloaded email and its attachments as files, ready for downstream nodes.

**How downstream nodes use the output.** Pass the downloaded files into [Read Files](./utility-nodes.md) and then into [InsurGPT nodes](./insurgpt-nodes.md) for extraction.

**Set it up**

1. Add **Download Email** after the Outlook Trigger.
2. Map **Access Token** from **Outlook: Auth** and **Message ID** / **User ID** from the trigger.
3. Connect it to your first file-processing node.

**Example.** In [Submission Intake](../use-cases/submission-intake.md), Download Email retrieves the broker's attachments so InsurGPT can extract the submission fields.

### Send Outlook Email

In the Nodes library this node is labelled **Send Email**.

**What it does.** Sends an email from the connected mailbox.

**Status:** Available.

**When to use it.** To acknowledge receipt, send a confirmation, or route correspondence as part of a flow.

**Configuration fields**

- **Access Token** — the token from **Outlook: Auth**.
- **User ID** — the sending mailbox.
- **To Recipients** — one or more recipient addresses.
- **Subject** — the subject line.
- **Body** — the message body.
- **Body Content Type** — **HTML** (default) or **Text**.
- **CC Recipients** / **BCC Recipients** — optional copies.
- **Save to Sent Items** — whether to keep a copy in Sent Items (default on).

**Inputs.** Recipients, subject, and body, plus the access token. Any of these can be mapped from earlier steps.

**Outputs.** A success indicator confirming the message was sent.

**Set it up**

1. Add **Send Email** where you want the flow to send mail.
2. Map **Access Token** and **User ID**, then set recipients, subject, and body — mapping in values from earlier steps where useful.
3. Connect it into the flow.

**Example.** After a submission is logged, Send Email returns an acknowledgement to the broker with the reference number captured during extraction.

### Mark Outlook Email as Read

In the Nodes library this node is labelled **Mark Email Read**.

**What it does.** Marks a message in the mailbox as read.

**Status:** Available.

**When to use it.** To keep a monitored mailbox tidy by marking messages a flow has already picked up.

**Configuration fields**

- **Access Token** — the token from **Outlook: Auth**.
- **User ID** — the mailbox owner.
- **Message ID** — the message to mark, mapped from the trigger.

**Inputs.** A message reference plus the access token.

**Outputs.** A confirmation that the message was updated.

**Set it up**

1. Add **Mark Email Read** after the message has been downloaded.
2. Map **Access Token**, **User ID**, and **Message ID**.

**Example.** Once Download Email succeeds, Mark Email Read marks the source message so it isn't reprocessed.

### Move Outlook Email

In the Nodes library this node is labelled **Move Email**.

**What it does.** Moves a message to another folder by folder ID.

**Status:** Available.

**When to use it.** To file processed mail into a specific destination folder when you know the folder's ID.

**Configuration fields**

- **Access Token** — the token from **Outlook: Auth**.
- **User ID** — the mailbox owner.
- **Message ID** — the message to move.
- **Destination Folder ID** — the ID of the target folder.
- **Mark as Read** — optionally mark the message read after moving (default off).

**Inputs.** A message reference and a destination folder, plus the access token.

**Outputs.** A confirmation that the message was moved.

**Set it up**

1. Add **Move Email** after processing completes.
2. Map **Access Token**, **User ID**, and **Message ID**, and set **Destination Folder ID**.

**Example.** After a submission is logged, Move Email files the original message into a "Processed" folder.

### Move Outlook Email to Folder

In the Nodes library this node is labelled **Move Email to Folder**.

**What it does.** Moves a message to a well-known folder by name.

**Status:** Available.

**When to use it.** The simplest way to file mail into a standard folder without looking up a folder ID.

**Configuration fields**

- **Access Token** — the token from **Outlook: Auth**.
- **User ID** — the mailbox owner.
- **Message ID** — the message to move.
- **Destination Folder** — one of **archive**, **drafts**, **inbox**, or **outbox**.

**Inputs.** A message reference and a named folder, plus the access token.

**Outputs.** A confirmation that the message was moved.

**Set it up**

1. Add **Move Email to Folder** where you want to file the message.
2. Map **Access Token**, **User ID**, and **Message ID**, then choose the **Destination Folder**.

**Example.** After acknowledgement, Move Email to Folder archives the source message.

---

## Guidewire

The Guidewire nodes read from and write to Guidewire ClaimCenter. Each one is a configured request to your ClaimCenter API: you provide the endpoint URL and headers (including authorization), choose the output format, and map the claim attributes you care about from earlier steps. These nodes are the common write-back step at the end of a claims flow.

**Shared prerequisites.** A reachable Guidewire ClaimCenter API endpoint and credentials authorized to read or modify claims. Store the endpoint base and any tokens as variables, and supply authorization through the node's **Headers**.

### Search for a Guidewire Claim

In the Nodes library this node is labelled **Search Claim**.

**What it does.** Looks up existing claims in ClaimCenter that match the criteria you provide.

**Status:** Available.

**When to use it.** To check whether a claim already exists before creating one, or to retrieve a claim ID needed for a later update.

**Configuration fields**

- **HTTP Method** — the request method for the search endpoint.
- **Guidewire API Endpoint** — the full URL to the ClaimCenter search endpoint.
- **Headers** — request headers, including authorization.
- **Output Format** — Full Response, Content Only, or Raw Bytes.
- **Search Parameters** — map ClaimCenter search attributes to values from previous steps.

**Inputs.** Search criteria mapped from upstream nodes.

**Outputs.** A count of matching claims and an array of the matching results.

**How downstream nodes use the output.** Use the count in a [Conditional Branching](./control-nodes.md) node to decide whether to create or update, and map a returned claim ID into **Update a Guidewire Claim**.

**Set it up**

1. Add **Search Claim** before any create or update step.
2. Set the endpoint and headers, and map your **Search Parameters** from extracted fields.
3. Branch on the result count.

**Example.** In a claims setup flow, Search Claim checks for an existing claim by policy number before the flow decides to create a new one.

### Create a Guidewire Claim

In the Nodes library this node is labelled **Create Claim**.

**What it does.** Creates a new claim record in ClaimCenter.

**Status:** Available.

**When to use it.** As the write-back step that turns an extracted submission into a claim in your system of record.

**Configuration fields**

- **HTTP Method** — the request method for the create endpoint.
- **Guidewire API Endpoint** — the full URL to the ClaimCenter create endpoint.
- **Headers** — request headers, including authorization.
- **Output Format** — Full Response, Content Only, or Raw Bytes.
- **Claim Fields** — map ClaimCenter claim attributes to values from previous steps (typically the output of an extraction node).

**Inputs.** Claim field values mapped from earlier steps.

**Outputs.** The created claim, including its new identifier.

**Write-back behavior.** This node writes to ClaimCenter. Because a re-run can create a duplicate, guard creation with **Search Claim** plus a conditional branch, or route uncertain cases to [Flag for Human Review](./utility-nodes.md) before writing.

**Set it up**

1. Add **Create Claim** after extraction and validation.
2. Set the endpoint and headers, and map extracted fields into **Claim Fields**.
3. Capture the returned claim identifier for any downstream steps.

**Example.** In a claims setup flow, Create Claim writes the extracted FNOL fields into ClaimCenter and returns the new claim number.

### Update a Guidewire Claim

In the Nodes library this node is labelled **Update Claim**.

**What it does.** Updates fields on an existing ClaimCenter claim.

**Status:** Available.

**When to use it.** To enrich or correct a claim — for example, adding extracted details to a claim you found with Search Claim.

**Configuration fields**

- **HTTP Method** — the request method for the update endpoint.
- **Guidewire API Endpoint** — the full URL to the ClaimCenter endpoint, including the claim ID.
- **Headers** — request headers, including authorization.
- **Output Format** — Full Response, Content Only, or Raw Bytes.
- **Update Fields** — map the claim attributes to update with values from previous steps.

**Inputs.** A claim identifier (usually from Search Claim) and the field values to apply.

**Outputs.** The updated claim.

**Write-back behavior.** This node modifies an existing record. Confirm you have the correct claim ID (from Search Claim) before updating, and validate values with [Field Validation](./utility-nodes.md) so you don't overwrite good data with low-confidence extractions.

**Set it up**

1. Add **Update Claim** after Search Claim returns a claim ID.
2. Put the claim ID into the endpoint URL, set headers, and map **Update Fields**.

**Example.** [Claim-to-Policy Comparison](../use-cases/claims-to-policy-comparison.md) updates the matched claim with the policy details confirmed during the flow.

---

## Not available

These app connectors are visible in the Nodes library but disabled. They cannot be added or configured, and have no setup steps until they are enabled.

| Node | Status |
| --- | :---: |
| Document Management | Not available |
| Claims Processing | Not available |
| Policy Administration | Not available |
| Cloud Storage | Not available |
| Customer Management | Not available |

## Security considerations

- **Keep secrets in variables.** Store client secrets, tenant IDs, and API tokens as environment variables and reference them from node configuration. Don't paste them into fields as constants.
- **Use least-privilege accounts.** Grant the connected mailbox and Guidewire credentials only the access the flow needs.
- **Tokens are passed, not stored.** Outlook action nodes receive the access token from **Outlook: Auth** at run time rather than holding their own credentials. Authorize once and map the token forward.
- **Scope variables appropriately.** Set connection variables in the environment where the flow runs, and scope them to the workspace, AI Agent, or flow that needs them. See [Configure environments and variables](./environments-variables.md).

## Troubleshooting

| Symptom | Likely cause | What to check |
| --- | --- | --- |
| Outlook nodes fail with an authorization error | The access token is missing, expired, or not mapped | Confirm **Outlook: Auth** runs first and its token is mapped into each action's **Access Token** field |
| Outlook action targets the wrong message | **Message ID** or **User ID** not mapped from the trigger | Re-check the mappings against the Outlook Trigger output |
| Guidewire node returns an error status | Wrong endpoint, missing authorization header, or bad payload | Set **Output Format** to Full Response and read the status code and content |
| Duplicate claims created | Create Claim re-run without a guard | Add **Search Claim** plus a conditional branch before Create Claim |
| Update applies to the wrong claim | Incorrect claim ID in the endpoint URL | Map the claim ID from **Search Claim** into the Update endpoint |

Inspect failed steps in [Run history](../monitor-review/run-history.md), fix the cause in the draft, and re-test before publishing. To rerun programmatically, use the [API rerun endpoint](/api/flow-executions#rerun-a-flow-execution).

## Where to go next

- [Configure triggers](./triggers.md) — set up the Outlook Trigger that feeds the Outlook nodes.
- [Node catalog](./node-catalog.md) — see every node and category at a glance.
- [Utility nodes](./utility-nodes.md) — Read Files, Field Validation, API Request, and Flag for Human Review.
- [Control nodes](./control-nodes.md) — branch before writing back to a system of record.
- [Configure environments and variables](./environments-variables.md) — store connection credentials safely.
- [Test and debug a draft](./test-debug-draft.md) — run a draft to validate a connection end to end.