Leader application & joiners/leavers
Pro feature
Requires a MIA Pro subscription.
Designate an application as the leader (for example your HRIS or your directory): MIA then relies on it to automate the access lifecycle as people join and leave.
Designating the leader application
Under Configuration → Organization, choose the leader application, or "None" to remove it. Every change goes through a confirmation that spells out its consequences. Only one application is the leader at a time. The Settings tab of each application says whether it is the leader, or why it cannot be.
Only applications synchronized by API that provide their users' email addresses can be the leader. On designation, MIA takes a reference snapshot of the existing workforce, so that not everyone is treated as a new joiner.
Changing it, or removing it, cancels the pending scheduled closings and deletes the pending automatic access requests. The assignment rules of the former leader are kept but hidden: they come back if it becomes the leader again.
Only arrivals of users are detected: with automatic creation off, a newcomer becomes an anomaly and creates no request.
When a person joins
When a new person appears in the leader application, MIA automatically creates an access request (see Access requests) and sends you an email leading to it. You just have to complete the request with the applications to open, through Add applications: nothing is opened without your approval.
Pre-filling the joiner request
Some leader applications describe your users with attributes such as division, department or job title. MIA shows them on the user's page, and you can use them to pre-check the applications of a joiner.
From Configuration → Kits and rules, Assignment rules section, create a rule such as "Department = IT and Job title = Lead → kit IT Pack". Every time an arrival is detected, MIA evaluates your rules: the applications of the kits whose conditions are all met arrive pre-checked in the Add applications panel of the request, along with the name of the kit that suggested them.
- A user satisfying several rules receives the union of their kits.
- A condition on an attribute the user does not carry is not met: a rule on three attributes only applies to users carrying all three.
- The observed combinations table, below your rules, shows the attribute combinations your users actually carry, how many people each concerns, and the ones no rule covers.
- A rule pre-checks, it opens nothing: you review, adjust and approve as usual.
- Rules apply to the arrivals to come. Editing a rule recomputes neither the requests already created nor the access already opened.
When an attribute is renamed
The names of the attributes and of their values come from your leader application, where you change them freely. If you rename a job title or a department there, MIA can no longer match the rules written on the former name: those rules then apply to nobody.
MIA tells you so in Configuration → Kits and rules: a banner counts the rules concerned, and the offending condition is highlighted within the rule. Editing the rule is enough to point it at the new name, with nothing to recreate.
MIA does not guess the match between the former name and the new one: your leader application keeps no trace of the former. Choosing the value that replaces the one that disappeared is therefore up to you.
This signal supposes MIA could read the list of attributes of your leader application. If the connection to that application is in error, nothing is signalled: the incident then shows on the application itself, in its synchronization status.
When a person leaves
When a person disappears from the leader application, MIA schedules the cascading closure of their access on the other applications, after a short grace period. If the person reappears in the meantime, the scheduled closure is cancelled automatically.
The applications where MIA cannot close accounts, manual ones included, are scheduled too: the cascade email lists them apart ("Accesses to close manually"), and MIA reminds you to close those accounts once due, never withdrawing the accesses automatically. If the person reappears, even after the date, the reminder stops.
Safeguards
- Detection is paused if the leader application hits a sync error, to avoid any wrong move.
- The initial reference snapshot avoids a flood of requests on activation day.
- Scheduled closures can be adjusted before they take effect.