A scheduled SAP BOE workflow that logs in through SSO usually runs fine for weeks, and then one day it doesn’t — the login step fails, and nothing about your workflow changed. That’s a different problem than setting automation up in the first place, and it has a shorter list of usual suspects than it feels like at 7am when a report didn’t show up.
The session actually expired, and that’s more common than it sounds
Sessions that “just stop working” are often exactly that: expired, not broken. One detail explains a lot of these cases — a cookie issued without an explicit expiry lives only in memory for that browser session and never gets written to the on-disk cookie store. It works today, and it’s gone the next time anything restarts, whether that’s the browser process, the machine, or just enough time passing. That’s frequently the whole explanation for “it worked yesterday and it’s gone today.”
The other common version is a mismatch between how long your application’s session lasts and how long the identity provider’s session lasts. If your automation’s session outlives the IdP’s, or vice versa, you get exactly the kind of intermittent failure that looks like a bug but is really just two systems with different clocks. Manual logout somewhere, an inactivity timeout, a VPN or IP change, or a security reset triggered from the identity-provider side can all end a session without anything on your end changing at all.
IdP-initiated vs. SP-initiated — the flow itself may not be as fixed as it looks
SAML-based SSO comes in two shapes. In an IdP-initiated flow, the identity provider starts the process and hands your application a signed response — simpler to configure, which is why a lot of SAP BOE deployments end up here, but the application can’t verify it actually solicited that login, which is weaker on replay protection. In an SP-initiated flow, your application starts the request first and validates the response against it — the more controlled, more security-conscious setup, and increasingly the one identity teams push toward as a best practice.
The reason this matters for automation specifically: if your organization’s IT or identity team changes which flow is in use — often as a security hardening step, not something announced to end users — a login sequence that worked one way can start behaving differently, even though “SSO” is still the word everyone uses for both. It’s worth asking whether anything changed on that side before assuming the automation itself is at fault.
Something changed on the identity-provider side, and it’s not yours to fix
The most frustrating category is the one where nothing about your recorded workflow is wrong at all — a conditional access policy tightened, a new MFA requirement rolled out, or an IP-based restriction got added, all on the identity-provider side. These show up as an automation failure, but the actual fix is a conversation with whoever administers SSO, not a change to the workflow.
This is also where Report Flow’s one real limitation on unattended login applies directly: if a login now requires a fresh MFA code or a push-notification approval on every sign-in, that’s not something any unattended scheduler can get past, because there’s no person there to approve it. If that’s what changed, the honest answer is that this specific step needs a human present — the rest of the workflow can still run, but that one login can’t be fully unattended anymore.
What to check, in order
- Try the login manually, once, the normal way. If SSO itself fails or behaves differently outside of automation too, the problem is upstream of your workflow entirely — talk to IT.
- Check the run log for exactly which step failed. A failure at the login step versus a failure three steps later after a successful login point at different causes, and the log tells you which one you’re actually dealing with.
- Ask whether anything changed with SSO policy recently — new MFA requirements, conditional access rules, or a switch between IdP- and SP-initiated flows. This is worth asking before re-recording anything.
- Re-record the login step if the answer is that the flow genuinely changed. A different SSO sequence needs to be captured again — editing the old steps won’t reproduce a flow that no longer exists.
Most of the time, “the SSO step stopped working” isn’t a flaw in the automation — it’s a session that expired on schedule, or a policy that changed somewhere you can’t see from the workflow itself.