# Get Node From Graph

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 a JiraUser is active before creating a Jira ticket)
* 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., `JiraUser`, `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 — use [NODE\_IN\_GRAPH](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions.md#node_in_graph-condition) or [ENTITY\_TYPE\_IN\_OUTPUT](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions.md#entity_type_in_output-condition) conditions to branch based on results.
{% 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.

## Example: Verify Jira User Before Provisioning

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

```mermaid
graph TD
    A[[Trigger: employment_status eq ACTIVE]] --> B([Get Node From Graph: JiraUser])
    B --> C{Entity Type In Output: JiraUser?}
    C -->|User found| D([Proceed with provisioning])
    C -->|User not found| E([Send Notification: create Jira account])
```

1. **Trigger condition:** `employment_status eq "ACTIVE"` — fires for new hires or active employees
2. **Get Node From Graph action:** Query for `JiraUser` with filter `email eq {email}` — looks up the user by their email address in the Jira integration
3. **ENTITY\_TYPE\_IN\_OUTPUT condition:** Check if the previous action returned any `JiraUser` nodes
   * **If true (user found):** Proceed with provisioning actions (e.g., assign Jira groups, sync attributes)
   * **If false (user not found):** Send a notification to the IT team to manually create the Jira account first

## 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., `JiraUser`, `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

Use [ENTITY\_TYPE\_IN\_OUTPUT](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions.md#entity_type_in_output-condition) to check whether the action returned any nodes of a given type, or [NODE\_IN\_GRAPH](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions.md#node_in_graph-condition) to check the graph directly. These conditions control which subsequent actions execute.

### 2. Filter template variables in subsequent actions

Subsequent Get Node From Graph or [Send REST Request](/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: Querying This Documentation

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

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

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

The question should be specific, self-contained, and written in natural language.
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.