> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/get-node-from-graph.md).

# Get Node From Graph

Query the Veza Access Graph for entities during workflow execution.

Queries the Veza Access Graph for entities during workflow execution. This is a **read-only lookup** that does not create or modify entities. Retrieved nodes are available to subsequent actions and conditions in the workflow.

**Example Use Cases:**

* Verify a user exists and is active in a target system before submitting a provisioning request (e.g., check that an `OktaUser` is active before assigning an application)
* Look up entity attributes from the graph to use in downstream transformer expressions
* Check if a role or group exists before attempting to assign it

| Setting           | Description                                                                                                                                                              |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Entity Type       | **(Required)** The type of entity to query in the Access Graph (e.g., `OktaUser`, `AwsIamRole`). Selected from a dropdown populated by the graph schema.                 |
| Filter            | **(Optional)** A SCIM filter expression to narrow results (e.g., `active eq true`). Supports transformer template variables that reference values from previous actions. |
| Limit             | **(Optional)** Maximum number of nodes to return. Default: 100. Maximum: 1000.                                                                                           |
| Properties to Get | **(Optional)** Specific entity properties to include in the results. Leave empty to return all available properties.                                                     |

{% hint style="info" %}
This action runs in the control plane, not on Insight Points. Results accumulate in the workflow context. To branch on the results, add a condition with a **Condition String** that references the retrieved node's attributes (see [Condition branching](#1-condition-branching)).
{% endhint %}

The SCIM filter supports dynamic template variables (e.g., `{attribute_name}`) that resolve at runtime using values from previous actions. See [Attribute Transformers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers.md) for details on template syntax.

{% hint style="info" %}
Entity types discovered through an [OAA connector](/4yItIzMvkpAvMVFAamTf/developers/api/oaa.md) are namespaced with the application type they came from — for example `OAA.Jira Cloud.User` rather than `JiraUser`. Pick the type from the dropdown rather than typing it, since the namespace depends on how the application is registered.
{% endhint %}

## Data freshness

Rather than re-running an identical query on every execution, Get Node From Graph can reuse a result Veza already computed. A stored result is reused only while it is less than five minutes old, measured from the time that result completed. Past five minutes the action runs a new query, so workflows act on values from the most recent extraction instead of a day-old snapshot.

This five-minute bound is specific to Lifecycle Management graph reads. Other callers of the same query service use its default of 24 hours, which is what this action used before the bound was introduced.

Two related behaviors affect what a workflow sees:

* When a matching query is still running, the action uses that query's result rather than starting another, regardless of when the query began.
* Lifecycle Management keeps a separate ten-minute cache for the single-node lookups used by other actions, such as relationship management. The five-minute bound applies to this action's queries and does not shorten that cache.

The staleness window is not configurable.

## Example: Verify Jira User Before Provisioning

This example shows a workflow that checks if a user exists and is active in Okta before submitting a provisioning request:

```mermaid
graph TD
    A[[Trigger: employment_status eq ACTIVE]] --> B([Get Node From Graph: OktaUser])
    B --> C{Condition String: OktaUser.is_active eq true}
    C -->|Matches| D([Proceed with provisioning])
```

1. **Trigger condition:** `employment_status eq "ACTIVE"` — fires for new hires or active employees
2. **Get Node From Graph action:** Query for `OktaUser` with filter `email eq {email}` — looks up the user by their email address in the Okta integration
3. **Condition String:** `OktaUser.is_active eq true` checks the `OktaUser` node that the previous action returned. When it matches, the condition's provisioning actions run (e.g., assign Okta groups, sync attributes). When the lookup returned no active `OktaUser`, the condition does not match and its actions are skipped.

## Output and Downstream Usage

Each retrieved node is an entity from the Access Graph with the following data:

| Field        | Description                                                                                                    |
| ------------ | -------------------------------------------------------------------------------------------------------------- |
| `id`         | The entity's unique graph identifier                                                                           |
| `type`       | The entity type (e.g., `OktaUser`)                                                                             |
| `properties` | A key-value map of the entity's attributes (filtered by Properties to Get, or all properties if not specified) |

Retrieved nodes are added to the **workflow context** and can be used in three ways:

### 1. Condition branching

Add a condition after the action and set its **Condition Type** to **Condition String**. The condition string is evaluated against the source identity and the nodes that earlier actions retrieved, so it can reference a retrieved node's attributes by prefixing them with the entity type (for example, `OktaUser.is_active eq true`). The condition controls which subsequent actions execute.

### 2. Filter template variables in subsequent actions

Subsequent Get Node From Graph or [Send REST Payload](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-rest-request.md) actions can reference retrieved node attributes in their SCIM filters and payloads using transformer template variables. The transformer service resolves `{EntityType.attribute}` expressions against the accumulated nodes.

For example, if a Get Node From Graph action retrieved an `OktaUser` node with `login = "jsmith@company.com"`, a subsequent action's filter could reference `{OktaUser.login}` to use that value.

> **Note:** The entity type prefix is case-sensitive and must match the graph type exactly (e.g., `OktaUser`, not `oktauser`). Attribute names are case-insensitive.

### 3. Chaining multiple graph lookups

Multiple Get Node From Graph actions can run in sequence. Each action's results accumulate in the workflow context, so later actions and conditions can reference nodes from any earlier action. This enables multi-step lookups — for example, first look up a user, then look up their manager.

{% hint style="info" %}
The graph lookup transformer functions [FROM\_ENTITY\_ATTRIBUTE and FROM\_MANY\_ENTITIES\_ATTRIBUTE](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers/transformer-reference.md) also query the Access Graph, but operate within attribute transformers rather than as standalone workflow actions. Use Get Node From Graph when you need to branch workflow logic based on the existence or attributes of graph entities.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/get-node-from-graph.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.