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.
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.
A monitor that never fires its findings port is good news, not a broken flow. It means there is nothing to report.
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.
Was this helpful?