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 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.
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.
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 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, fix the cause in the draft, and re-test before publishing a corrected version — see Test and debug a draft. To trigger a rerun programmatically without changing the draft, use the API rerun endpoint. For write-back steps, guard against duplicates and partial writes using Control nodes and Field Validation, and route exceptions to a person with Flag for Human Review.
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
- Add MS Graph Auth near the start of your flow.
- Set Base URL and Tenant ID, and map the client credentials in Request Body from variables.
- 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 and then into InsurGPT nodes for extraction.
Set it up
- Add Download Email after the Outlook Trigger.
- Map Access Token from Outlook: Auth and Message ID / User ID from the trigger.
- Connect it to your first file-processing node.
Example. In Submission Intake, 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
- Add Send Email where you want the flow to send mail.
- Map Access Token and User ID, then set recipients, subject, and body — mapping in values from earlier steps where useful.
- 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
- Add Mark Email Read after the message has been downloaded.
- 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
- Add Move Email after processing completes.
- 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
- Add Move Email to Folder where you want to file the message.
- 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 node to decide whether to create or update, and map a returned claim ID into Update a Guidewire Claim.
Set it up
- Add Search Claim before any create or update step.
- Set the endpoint and headers, and map your Search Parameters from extracted fields.
- 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 before writing.
Set it up
- Add Create Claim after extraction and validation.
- Set the endpoint and headers, and map extracted fields into Claim Fields.
- 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 so you don't overwrite good data with low-confidence extractions.
Set it up
- Add Update Claim after Search Claim returns a claim ID.
- Put the claim ID into the endpoint URL, set headers, and map Update Fields.
Example. Claim-to-Policy Comparison 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.
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, fix the cause in the draft, and re-test before publishing. To rerun programmatically, use the API rerun endpoint.
Where to go next
- Configure triggers — set up the Outlook Trigger that feeds the Outlook nodes.
- Node catalog — see every node and category at a glance.
- Utility nodes — Read Files, Field Validation, API Request, and Flag for Human Review.
- Control nodes — branch before writing back to a system of record.
- Configure environments and variables — store connection credentials safely.
- Test and debug a draft — run a draft to validate a connection end to end.