Most organisations do not struggle with Microsoft 365 because the platform is incapable. They struggle because the work around it is still being run like a collection of one-off admin tasks.
A joiner starts on Monday and someone has to remember to assign licences. A manager changes divisions and someone has to update groups. A shared mailbox needs temporary access for a project and someone has to remove it later. A distribution list needs to reflect roster changes every week and someone is still doing it by hand.
At first, this looks manageable. Then the organisation grows, teams become more distributed, exceptions pile up, and the environment starts to depend on tribal knowledge instead of clear operational logic.
That is usually the point where someone says, “we should automate this.”
They are right. But this is also where many Microsoft 365 identity automation efforts begin to fail.
The failure is rarely because automation is a bad idea. It is because too many implementations stop at the first layer. A script gets written. A scheduled task is created. A service account is granted broad permissions. The automation technically works, but only under ideal conditions, and only as long as the person who wrote it is still around to explain what it does.
That is not identity automation in any serious operational sense. That is task execution.
Real identity automation has to survive staff changes, exceptions, bad source data, delayed approvals, mailbox ownership disputes, business restructures, and the quiet operational messiness that exists in every real environment.
This is where the gap appears between a script that works in a lab and a system that can be trusted in production.
The common pattern that breaks down
A very common starting point looks like this:
- HR or operations sends a spreadsheet or export
- An administrator runs a script or triggers a scheduled job
- The script reads a few fields
- It applies group membership changes, mailbox permissions, or licence assignments
- A few basic logs are written to a console window or text file
For a small environment, that can feel like a win. Manual effort drops. The process is faster. The same person no longer has to click through ten admin portals to complete one request.
The problem is that the design still assumes the surrounding world is neat, stable, and predictable.
In reality:
- source data is incomplete or arrives late
- naming conventions drift over time
- exceptions are not documented properly
- some access should be temporary, not permanent
- ownership of shared resources changes between teams
- approvals matter for some changes but not others
- a single failed call can leave a user half-updated
- operators still need to know what happened without reading code
Once those conditions appear, the first-generation automation begins to show cracks. The diagram below shows the difference between that first-generation pattern and a governed automation layer:
Basic Automation - first-generation pattern
Governed Automation Layer
Why default features and ad hoc scripting are not enough
Microsoft 365 provides a strong platform, but most identity and access workflows inside organisations span more than the native admin surfaces themselves.
The missing problem is not usually the ability to perform an action. It is the ability to decide when the action should happen, why it should happen, who owns the decision, how exceptions should be handled, and what evidence exists after the fact.
You can assign a licence. You can add a user to a group. You can grant mailbox permissions. You can update attributes in Entra ID.
None of that by itself gives you governed automation.
What organisations actually need is a control layer around those actions.
Without that control layer, identity automation tends to fail in six predictable ways.
1. No rules engine, only hard-coded logic
The first major failure point is logic embedded directly inside scripts.
This usually starts innocently. Someone writes conditions such as:
- if department equals Finance, assign these groups
- if location equals Sydney, apply this mailbox rule
- if job title contains Manager, add approval access
That works until the business changes.
A new brand is added. A division gets renamed. A temporary operating model is introduced for a merger. A contractor cohort needs different access from permanent staff, even though they share the same department.
Now the automation has to be edited every time the business shifts.
That creates two problems.
First, the automation becomes fragile because every change is a code change. Second, operational ownership stays locked inside IT or with a specific engineer.
A rules engine changes that.
The right model is not to bury business logic inside a script. The right model is to define rules in a controlled, structured way so they can be reviewed, versioned, understood, and changed safely.
For example, instead of hard-coding who gets access to a regional sales mailbox, define the conditions that drive that membership:
- employment status must be active
- business unit must be Sales
- region must be ANZ
- worker type must be permanent or approved contractor
- start date must be current
- end date must not have passed
Now the behaviour is explainable. It can be tested. It can be reviewed by the business owner. It can evolve without turning every operational change into a script rewrite.
That is the difference between automation that belongs to an engineer and automation that belongs to the organisation.
2. No schedule awareness for time-based access
A surprising amount of Microsoft 365 identity work is time-sensitive.
Not just onboarding and offboarding, but access that needs to begin, end, or change according to a business schedule.
Examples include:
- a shared mailbox delegated to a project team for six weeks
- a distribution list that should reflect seasonal staffing
- a duty roster mailbox that changes ownership by day or shift
- temporary assistant access for executive support coverage
- brand or campaign-based memberships that start on launch day and end after the campaign closes
When teams try to automate this without schedule awareness, they often fall back to one of two bad models.
Either they grant access and rely on someone to remember to remove it later, or they create a blunt recurring job that recalculates membership without a clear understanding of effective dates and expiry windows.
Both approaches create risk.
The first leads to lingering access. The second leads to unpredictable behaviour when source data changes late or conflicts with special cases.
Real identity automation needs to understand time as a first-class concern.
That means:
- effective start dates
- end dates and expiry handling
- recurring schedules where relevant
- grace periods where required
- awareness of weekends, roster timing, or business cutover windows
- the ability to preview upcoming changes before they are applied
Consider a practical example.
An organisation has a customer service mailbox that needs different delegate access during weekday business hours, after-hours escalation periods, and public holiday coverage. This is not unusual. It can reflect support rosters, outsourced overflow teams, or brand-specific handling.
A basic script might grant and remove access on a timer. A better system understands the schedule model, validates who should hold access for the active period, records the reason, and produces an operator-facing report showing what is about to change and what changed last run.
That is the level where automation becomes operationally safe.
3. No config-driven ownership
One of the fastest ways for identity automation to become unmanageable is when nobody can tell who owns a rule, a mailbox, a list, or a particular exception.
This shows up constantly in real environments.
A shared mailbox was created years ago. The original manager left. Several teams assume somebody else owns it. Access requests still arrive. No one wants to be the person who removes a permission and breaks a business process.
If the automation layer has no concept of ownership, everything gets pushed back to IT. That means IT becomes the operational bottleneck for business decisions it should not be making.
Config-driven ownership fixes this by making ownership explicit.
That can include:
- business owner
- technical owner
- approval contact
- escalation contact
- service classification
- access sensitivity level
- allowed automation path
- exception handling rules
This matters because not all actions should be automatic in the same way.
Some can be fully rules-driven. Some should require owner approval above certain thresholds. Some should allow temporary access but block permanent access. Some should only run if the source system marks the record as approved.
A good automation design does not just know what resource is being changed. It knows who has standing authority over it and what policy applies to that authority.
This is especially important for shared mailboxes, distribution lists, role-based groups, and cross-functional team access where the resource itself outlives the people around it.
4. No proper auditability
This is the one that hurts later.
When an access issue is raised, the question is almost never just “what is the user’s access right now?” The more important questions are:
- when did it change
- who or what caused the change
- what source data triggered it
- what rule evaluated to true
- what approval existed, if any
- what else changed in the same run
- was the change expected or exceptional
If the only record is a console transcript, a text file on a server, or the memory of the engineer who wrote the script, the automation is not auditable in any meaningful operational sense.
For identity automation to be trusted, every significant change should leave a clear trail.
That trail should usually include:
- the entity changed
- the before and after state where relevant
- the source record or triggering event
- the rule or policy path used
- the execution time
- the outcome
- any warnings or exceptions
- the system or operator identity behind the action
This is not bureaucracy. It is what turns automation into something the organisation can defend.
It matters during access reviews. It matters during incident response. It matters when a business owner disputes a change. It matters when the same class of failure happens twice and someone needs to identify the pattern.
In practice, auditability is one of the biggest differences between “we automated some admin work” and “we implemented a governed identity process.”
5. No retries, no resilience, and poor failure handling
Many Microsoft 365 automation efforts fail not because the logic is wrong, but because the environment is real.
APIs time out. Transient errors occur. Directory state is not always immediately consistent. A dependency returns incomplete data. A mailbox operation succeeds but the confirmation read does not. A downstream system is late.
A brittle automation flow treats these as edge cases. A production-grade automation flow treats them as normal conditions to design for.
That means thinking through questions such as:
- which operations are safe to retry
- which operations must be idempotent
- what should happen if step three fails after step two succeeded
- when should the run pause, continue, or raise an exception
- how are partial updates detected and reconciled
- how will operators know which items need intervention
This is where a lot of supposedly successful automation breaks down under real operational load.
A user gets added to the right groups but not assigned the expected licence. A shared mailbox permission is granted twice through overlapping jobs. A delayed source feed causes a removal to happen one run too early. A failed run gets re-executed manually without understanding what already completed.
Once that happens, trust drops fast.
Operators stop relying on the automation because they no longer believe it is safer than manual handling. The entire point of the system begins to erode.
Resilient identity automation should be designed around safe re-execution, clear transaction boundaries where possible, meaningful retry rules, and visible exception queues for anything that cannot be resolved automatically.
6. No reporting for the people who actually run the environment
One of the most common design mistakes is building automation that only developers can interpret.
The job runs. A log file exists. A PowerShell transcript is captured. The engineer who wrote it can explain the output.
That is not enough.
In real environments, the people responsible for day-to-day operations are often service desk leads, infrastructure teams, operations managers, platform owners, or internal IT staff who need concise, reliable reporting without reading code or trawling raw logs.
They need to know things like:
- what changed today
- what is queued for the next run
- which items failed and why
- which resources have unusual exception patterns
- which rules are generating the most churn
- which access grants are due to expire
- where manual intervention is required
This reporting layer is often the difference between automation that becomes part of daily operations and automation that remains a black box.
If people cannot see what the system is doing, they do not really trust it. If they cannot explain it to auditors, managers, or business owners, they do not really own it.
Operator-facing reporting is not an optional extra. It is part of the product.
A real-world example of where basic automation falls short
Consider a multi-brand organisation where staff can move between divisions, act in higher duties temporarily, and provide backfill support across shared mailboxes.
The organisation wants to automate:
- distribution list membership
- shared mailbox delegate access
- selected licence assignments
- department-based role groups
The first attempt is usually straightforward. Pull staff records nightly, match them by department and title, then apply membership updates.
That works until reality shows up.
A user belongs to Brand A permanently but is seconded to Brand B for eight weeks. An executive assistant needs temporary access to a mailbox only while another assistant is on leave. A senior manager should receive role-based access only when the HR record shows the acting arrangement as approved. A contractor should be included in operational communications but excluded from sensitive groups. A mailbox should remain owned by a business unit even though the current people with access rotate regularly.
None of these are exotic requirements. They are normal.
The problem is that they are normal in a way that simplistic automation does not model well.
Now the script starts accumulating overrides. Special cases are added into the code. The person maintaining it keeps a mental map of what should not be touched. Documentation falls behind. A run fails after a source export arrives late. Access remains wrong for a subset of users. Someone spends half a day validating the outcome manually.
At that point, the organisation has not escaped manual work. It has only moved the manual work further up the stack.
What real Microsoft 365 identity automation needs instead
When identity automation works properly, it is not because the underlying admin action is complicated. It is because the surrounding operational design is disciplined.
The environments that succeed usually have the following layers in place.
A controlled rules model
The logic that drives access decisions is structured, reviewable, and not hidden inside scattered scripts.
Time-aware execution
The system understands effective dates, expiry, temporary access, and scheduled transitions.
Clear ownership and approval paths
Resources, rules, and exceptions have named owners and defined policy behaviour.
Full audit history
Changes can be traced clearly, with enough context to explain what happened and why.
Resilience and safe reprocessing
Transient failures, delayed source data, and partial completion scenarios are anticipated and handled cleanly.
Reporting designed for operators
The people running the environment can see outcomes, exceptions, upcoming changes, and trend patterns without technical archaeology.
When these layers exist, the conversation changes.
The organisation stops asking whether a script ran successfully and starts asking whether access policy is being enforced correctly.
That is a much more valuable place to be.
The business case is bigger than labour saving
A lot of automation discussions start with time savings, and that is fair. Manual Microsoft 365 identity administration consumes a surprising amount of operational effort.
But the stronger business case is broader than reduced admin hours.
Good identity automation helps reduce:
- access drift over time
- dependency on specific individuals
- inconsistent handling across teams
- operational delays for joiners, movers, and leavers
- security exposure from lingering permissions
- audit pain when historical evidence is missing
- service disruption caused by unclear mailbox and list ownership
It also improves things that are harder to quantify at first glance:
- confidence in operational controls
- consistency across business units
- quality of access reporting
- speed of exception handling
- sustainability of the environment as the organisation grows
That is why serious organisations eventually move beyond ad hoc scripting. Not because scripts are useless, but because scripts alone do not give them governance.
Where RePass Cloud fits
At RePass Cloud, this is exactly the gap we design for.
We do not treat Microsoft 365 identity automation as a pile of disconnected admin tasks. We treat it as an operational system that needs rules, ownership, time-awareness, auditability, resilience, and reporting built in from the beginning.
That is the difference between automating activity and implementing control.
For some organisations, the right answer is targeted automation around a specific pain point such as onboarding, shared mailbox access, or schedule-driven distribution lists.
For others, the need is broader: a governed identity automation layer that connects HR changes, access rules, operational events, and Microsoft 365 actions into something the organisation can run safely over time.
In both cases, the goal is the same.
Remove manual effort, yes. But do it in a way that reduces risk, improves visibility, and still makes sense six months later when the business has changed again.
Where most implementations actually stop
If Microsoft 365 identity automation has not delivered in your environment, the culprit is usually the same: the implementation stopped at the point where it became technically functional but before it became operationally trustworthy.
Writing a command that adds a user to a group is the easy part.
The surrounding system - the part that decides when the change should happen, who owns the decision, how long the access should remain valid, what should happen when source data is incomplete, and how the organisation proves later that the change was appropriate - that is the part that most first-pass efforts never reach.
That gap is not a reason to avoid automation. It is a reason to approach it, with a complete design from the start.