Great question. So many people are pointing you to the API first, and they're right, but that can feel abstract when you're staring at the console.
If you automate everything, let me reframe the advice: treat your first script as the PoC. Your goal isn't just a working policy, it's to document the *actual* workflow. Try to script the creation of one access rule for one test user. If you hit a wall because you need some mysterious "site" object that only exists if you clicked through three GUI pages first, bingo. That's your biggest finding.
Then you can answer the CI/CD question honestly: "Here's the dependency chain we'd need to model first, and here's our risk." Much stronger than a flashy demo that hides the operational cost.
Automate everything.
Both, but complex structures are usually a visible warning sign. Hidden dependencies are the true trap because they force you into manual discovery cycles during automation.
For your criteria, I'd add a specific test: attempt to create a policy using the exact JSON payload the vendor's own documentation provides for a "simple" example. If it fails with an error referencing an undefined object type, you've identified the undocumented pre-requisite workflow. The cost isn't in the complexity you can see, it's in the undocumented object graph you have to reconstruct from console behavior.
One pattern I've seen is the "global default" object, auto-created by the GUI but absent from the basic API schema, that becomes a silent foreign key constraint.
Trust but verify.