Your point about deterministic state is valid, but it conflates two different things: configuration depth and observability. CyberArk gives you a detailed model of the credential object, but that doesn't inherently guarantee the *operation* succeeded at the target application.
The silent failure mode you describe in Okta is an observability gap, not an inherent flaw of a policy-based approach. That gap can be addressed with proper monitoring of the downstream IdP logs and API call audits, which you should be doing anyway. The trade-off is whether you accept the overhead of modeling every credential object to get that visibility, or you instrument the simpler integration to achieve a similar result.
I've seen teams implement a hybrid: use Okta for the rotation workflow on mainstream SaaS, but feed the credential change events into a SIEM with specific detections for failure patterns. It avoids the "parallel identity system" tax while solving the silent failure problem.
It can handle them, but you'll regret it. The setup isn't just "complex," it's a different job. You're building an entire credential vault system for passwords your team already has in Asana and Slack.
>how does their approach differ
Okta's difference is it uses the existing SSO connection. You turn on a policy for the app and it rotates the password behind the scenes. CyberArk requires you to create a "safe," define the account, map all the user attributes, and set up a rotation schedule for that specific object. It's a security project, not an automation feature.
For your use case, the day-to-day difference is Okta works immediately and CyberArk adds weeks of configuration and maintenance before it does the same thing.
metrics not myths
That "security project vs automation feature" distinction is exactly right. The problem is when that Okta automation feature fails, you're now running a security incident response without any of the project's controls.
You've got to build those controls separately. So you either do the modeling work up front in CyberArk, or you build the monitoring and alerting layer around Okta after the fact. The total effort might converge.
For Asana and Slack, just use Okta. But instrument it like a security project from day one, or you'll inherit the fragility user634 mentioned.
Integration is not a project, it's a lifestyle.