The name should only change if you (or another admin) change it. For the sake of argument; an admin could just as easily delete the role, the ID would be lost, and it would have the same effect as changing the name, although it would be unrecoverable.
I’m not sure I see the benefit of using ID vs name in the scenario you are describing.
Additionally, the workaround I described above requires writing the role IDs directly in the action, which is not an elegant solution, and could cause pain down the road.
Not sure I buy your argument. There’s a huge difference between changing a name (that has no visual relation to app logic) and deleting the role itself. There’s a reason you can change the name, and not the ID. The ID is IDentifying. The name is a name.
Certainly, but neither will happen without admin intervention, and you can expect the name to remain static unless you choose to change it.
There isn’t a way to get role IDs in an Action without calling the management API (which is not recommended as you will quickly run into management API rate limits), or writing the values directly in the code.
Can you expand on your use case? When are you making the call to the management API?
I understand that the name won’t change if you don’t change it, but there’s no indication in the GUI that changing the name will break the app. On the contrary, as you’re able to change the name, it’s presented as a harmless action. Which won’t be true when using the name as an identifier.
So, I did this for now, as I don’t expect to hit rate limits:
As you say, it’s not ideal, but as far as I can tell it’s the only way. So much hassle, instead of Auth0 just exposing more than just the name of the role (for some reason). Will add an feature request.
As for my use case, I have a SPA, and use the role (id) to control GUI access.