> For the complete documentation index, see [llms.txt](https://hub.equipme.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.equipme.io/documentation/automation/connectors/microsoft-entra-id-connector/working-with-the-connector.md).

# Working with the Connector

Three patterns repeat across the whole connector. Once you know them, every component page is short, because the behaviour is already familiar.

#### How lists are returned

Every component whose name starts with **List** offers an **Output Type** setting. It decides the shape of what leaves the component, and it usually decides the shape of the rest of your flow.

| Output Type        | What you get                                                    | Use it for                                                              |
| ------------------ | --------------------------------------------------------------- | ----------------------------------------------------------------------- |
| All items at once  | One message with the complete list under `result`, plus `count` | Sending a report by email, handing data to another system               |
| One item at a time | Each element separately, with `index` and `count`               | Running an action per element, such as assigning a license to each user |
| First item only    | Just the first element                                          | Simple "is there any at all?" checks                                    |
| Store to CSV file  | A saved CSV file and its `fileId`                               | Exports, archiving, attachments                                         |

The choice between the first two is the one that matters most. **All items at once** keeps the flow simple but leaves you with a collection to handle. **One item at a time** turns the rest of the branch into a loop that runs once per element.

#### How monitors report

Every component whose name starts with **Monitor** follows the same shape, so you can build supervision without knowing filter components.

Each monitor has two output ports:

**findings** fires only when there is something to report. It carries a plain-language summary in `message`, the counts in `count` and `checked`, and the analysed list in `result`. Every entry in that list comes with its own ready-made `detail` message, so you can forward it without writing your own text.

**ok** fires when everything is in order. Connect it to a log entry if you want a daily confirmation that the check actually ran.

The standard recipe is three components long: a scheduler trigger, the monitor, and the **findings** port going to an email, a ticket or a chat message. That is a complete supervision workflow.

{% hint style="info" %}
A monitor that never fires its findings port is good news, not a broken flow. It means there is nothing to report.
{% endhint %}

#### How triggers behave

Triggers come in two kinds, and the difference decides how quickly your flow reacts.

**Polling** triggers check on a cycle and fire when they find something new.

**Webhook** triggers react immediately, because Microsoft Graph notifies equipme through a subscription rather than being asked.

When a component page names its trigger type, this is what it means. Choose webhook triggers for provisioning work where delay is visible to people, and polling where a cycle of minutes or hours is fine.


---

# 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 dynamically by asking a question.

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

```
GET https://hub.equipme.io/documentation/automation/connectors/microsoft-entra-id-connector/working-with-the-connector.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.