Internal operations
Your own back-office, automated without waiting for the platform team.
Every company has a handful of internal consoles that were never meant to be integrated. They sit behind the identity provider, they have no API, and the queue to get one is six months long. The work still has to happen.
Twelve clicks in a console, forty times a week
-
Get through the identity provider
Azure AD or Okta, with conditional access: device compliance, a push notification, sometimes a number match. This is the step that stops conventional automation dead.
-
Navigate to the thing
Admin console → the right tenant → the right tab → filter → export. The route is stable enough that a person does it from memory, and unstable enough that nobody wrote it down.
-
Do the thing
Reset a user. Pull a report. Flip a feature flag. Approve a request. Reconcile two systems that disagree.
-
Paste the result somewhere
Into a ticket, a spreadsheet, a Slack channel. This is almost always the step a human resents most.
The login lives in a frame you do not own
This is the case that separates a browser agent from a script. Okta, Azure AD and Google Sign-In render their login inside a cross-origin iframe.
- Ordinary automation cannot see inside. The frame is a different origin; the accessibility tree stops at the boundary and element handles do not cross it.
- We address it directly. Read, type and click inside cross-origin frames, so the SSO flow completes as written.
- After capture it stops mattering. The session is injected before the first navigation, so no run ever sees the login screen again.
Capture the SSO flow once. Every run afterwards starts already signed in, no push notification, no device check, no MFA prompt.
What teams actually automate here
- User lifecycle: provision, suspend and off-board across the consoles that your IdP does not have a connector for.
- Report pulls: scheduled exports from internal analytics, billing and support consoles into a warehouse.
- Reconciliation: compare what the internal console says against what the system of record says, and flag drift.
- Bulk corrections: the data-cleanup job that has a UI but no bulk endpoint.
The objection you should raise
Shouldn’t we just get an API? Often yes, and if the platform team will build one, use it. The honest framing is that PreLogin is what you do for the six consoles that will never justify engineering time, and it stops being needed the day one of them gets a proper endpoint.
On internal security review
This use case gets the most scrutiny, correctly. Because runs act under a real employee’s session, we recommend a service account with the narrowest role that can do the job, a dedicated tenant, and full reliance on the audit log. Every run records what it did and which actor it ran as.
Pick one console and one job.
The one your team does most often and complains about most.