ManageEngine ADManager Plus
Identity & SecurityConnect AI agents to a self-hosted ManageEngine ADManager Plus instance. Agents read and update Active Directory users, groups, and OUs, create computers and contacts, disable computers, and run orchestration templates for the full account lifecycle.
What This Integration Enables
This connector talks to your own ADManager Plus server, not a vendor cloud. You supply the base URL of your install, including protocol and port, and a technician authtoken generated in the console under My Account then Active Authtokens, which the service sends in the Authorization request header. The legacy REST endpoints accept that token as a query parameter and this connector deliberately does not use them, so the token stays out of server logs. Both configuration values are per connection rather than shared.
The action set is worth reading precisely, because the API v2 surface is narrower than a directory management product might suggest and building against capabilities that are not there is the usual way this goes wrong. Agents can read users, groups, computers, contacts, and organizational units with SCIM style filtering, field selection, sorting, and pagination. They can update users, groups, computers, contacts, and OUs. Direct creation exists for computers and contacts only, and direct deletion exists for contacts only. There is no create, delete, password reset, or enable and disable action for user accounts on this surface. That entire lifecycle runs through Execute Orchestration, which applies an ADManager Plus orchestration template to objects selected by a filter and returns an execution ID you poll with Get Execution Status. List Orchestration Templates returns the templates configured on your server so a flow can reference one by ID.
The single most important property of this connector is that every write is filter scoped. Update, Disable, and Delete operations do not take an object ID. They take a SCIM filter such as LOGON_NAME eq "jdoe" plus a domain, and an attributes object holding the values to apply. The filter defines the blast radius. A filter that matches one account and a filter that matches four hundred are the same call with different text, and there is no confirmation step in the API between them. The connector exposes no triggers: nothing in ADManager Plus starts a FlowRunner flow and there is no event subscription, so joiner, mover, and leaver flows are started by the system that actually knows about the change, typically an HR platform or a ticket queue, and this connector is what they call.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Offboarding on the Last Working Day
An HR record is marked final and carries a last working day. On that date the flow starts, and the agent resolves the leaver to a logon name and builds the SCIM filter it intends to use. Before writing anything it runs List AD Users with that identical filter and reads back the matched accounts. The IT owner sees the actual names and count, approves, and the agent runs Execute Orchestration with the standard offboarding template, which bundles the disable, group removals, and mailbox handling the organization agreed on once rather than a checklist an admin repeats per leaver. The agent polls Get Execution Status until the run reports complete and posts the execution ID back to the ticket.
Provisioning a New Starter From the Ticket
A new starter ticket is approved with a role, a department, and a manager. There is no create user action here, so the agent does the right thing rather than the improvised thing: it calls List Orchestration Templates, selects the provisioning template that matches the role, and runs Execute Orchestration with it. The template supplies the naming standard, the OU, the group memberships, and the mailbox setup that the directory team maintains centrally. The agent then runs List AD Users to confirm the account now exists with the expected attributes, and posts the result alongside the identity provider steps handled in Entra ID or Okta.
Directory Hygiene on Stale Computer Accounts
A quarterly cleanup targets computer accounts that have not been seen in months. The agent runs List AD Computers with a filter on the relevant attributes and assembles the candidate list with names, operating systems, and OUs. It does not disable anything on that list by itself. It publishes the list for review, and once the set is confirmed it runs Disable AD Computers against the approved filter rather than a deletion, so the accounts can be re-enabled if a machine turns out to be a laptop in a drawer rather than a decommissioned desktop. Contacts follow the same shape, except that Delete AD Contacts is permanent and gets a firmer confirmation.
Human-in-Loop Highlight
In this connector the approval is not about the action, it is about the filter. Update AD Users, Update AD Groups, Disable AD Computers, Delete AD Contacts, and Execute Orchestration all select their targets with a SCIM filter, and nothing in the API tells you how many objects that filter matched until after it has finished matching them. An operator who approves "disable the leaver's account" has approved an intent. What actually runs is a string, and a slightly loose one takes access away from people who came to work that morning. So the agent never routes the intent for approval. It routes the set. Before any filter scoped write, it runs the corresponding List action with the byte identical filter, and posts the result to the IT owner: "About to run Execute Orchestration with template [name] against domain [domain] using filter [filter]. That filter currently matches [n] objects: [names]. Approve this exact set, narrow the filter, or cancel?" The owner is looking at names and a count, not at syntax. On approval the agent runs the write with the same filter it previewed, then polls Get Execution Status and records the execution ID against the ticket. Reads run freely all day. Nothing that changes who can log in runs on an unreviewed filter. That is human-in-the-loop applied to the thing that actually carries the risk.
Agent Capabilities
17 actionsUser Management
2- List AD Users Retrieves Active Directory user accounts across one or more domains configured in ADManager Plus. Supports SCIM style filtering, field selection, sorting, and pagination. Used to locate specific accounts and, critically, to preview exactly which accounts a filter matches before a write runs with that same filter.
- Update AD Users Updates Active Directory user accounts in a single domain. The accounts to modify are selected with the filter parameter, and the attributes object holds the values to apply. Optionally references an ADManager Plus user modification template to supply defaults. Filter scoped, so it is routed for approval on the matched set.
Group Management
2- List AD Groups Retrieves Active Directory groups across one or more domains, including group name, scope, SAM account name, and distinguished name. Supports SCIM filtering, field selection, sorting, and pagination.
- Update AD Groups Updates Active Directory groups in a single domain. The groups are selected with the filter parameter, and the attributes object holds values such as name, description, group type, members, and Exchange settings. Membership changes grant or remove access, so this is routed for approval on the matched set.
Computer Management
4- List AD Computers Retrieves Active Directory computer accounts across one or more domains, including computer name, operating system, and SAM account name. Supports SCIM filtering, field selection, sorting, and pagination.
- Create AD Computers Creates one or more Active Directory computer accounts in a single domain. Each item in the computers list is an object of attributes such as name, sAMAccountName, OUName, description, and memberOf. Optionally references a computer creation template.
- Update AD Computers Updates Active Directory computer accounts in a single domain. The computers are selected with the filter parameter, and the attributes object holds values such as name, description, and OUName.
- Disable AD Computers Disables Active Directory computer accounts in a single domain, selected with the filter parameter. Preferred over deletion in cleanup workflows because a disabled account can be restored if the machine turns out to still be in use.
Contact Management
4- List AD Contacts Retrieves Active Directory mail contacts across one or more domains, including common name, distinguished name, email address, and OU. Supports SCIM filtering, field selection, sorting, and pagination.
- Create AD Contacts Creates one or more Active Directory mail contacts in a single domain. Each item in the contacts list is an object of attributes such as name, displayName, mail, description, and memberOf. Optionally references a contact creation template.
- Update AD Contacts Updates Active Directory mail contacts in a single domain. The contacts are selected with the filter parameter, and the attributes object holds values such as name, description, mail, and memberOf.
- Delete AD Contacts Deletes Active Directory mail contacts in a single domain, selected with the filter parameter. This is the only deletion on this surface and it is permanent, so it runs only against a filter whose matched set a person has reviewed.
OU Management
2- List AD OUs Retrieves Active Directory organizational units across one or more domains, including name, distinguished name, city, country, and manager. Supports SCIM filtering, field selection, sorting, and pagination.
- Update AD OUs Updates Active Directory organizational units in a single domain. The OUs are selected with the filter parameter, and the attributes object holds values such as description, managedBy, and address fields.
Orchestration
3- List Orchestration Templates Retrieves the orchestration templates configured in ADManager Plus, including template name, description, and ID. Used to find the template ID for a provisioning, password reset, or enable and disable sequence, since those lifecycle operations are not exposed as direct actions.
- Execute Orchestration Runs an orchestration template against Active Directory objects selected by a filter in a single domain. Templates perform bundled actions such as creating or provisioning users, resetting passwords, and enabling or disabling accounts. Returns an execution ID for polling. This is the widest write in the connector and it always runs against a filter whose matched set has been approved.
- Get Execution Status Retrieves the current status of an orchestration execution using the execution ID returned by Execute Orchestration. Used to confirm the bundled actions completed and to attach the outcome to the originating ticket.
Frequently Asked Questions
What can FlowRunner do with ManageEngine ADManager Plus?
FlowRunner agents can run List AD Users, Update AD Users, and List AD Groups in ManageEngine ADManager Plus, plus 14 more actions.
Does connecting ManageEngine ADManager Plus to FlowRunner require OAuth?
No. ManageEngine ADManager Plus connects to FlowRunner with an API key, no OAuth flow required.
Can ManageEngine ADManager Plus trigger a FlowRunner workflow automatically?
ManageEngine ADManager Plus doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with ManageEngine ADManager Plus
$100 in credits. No card required. Connect in minutes.