Oracle Visual Builder Studio lets you automate the deployment of your applications to various instances of Visual Builder across tenancies. One area that caused some confusion is how the roles that are defined in VB are mapped and maintained across the IDCS instances in various tenancies when you deploy through VB Studio. In this blog we'll try and clarify this.
A key point to know is that after the first deployment of an app, if this deployment is to a different instance then the one you develop on, you need to go into the IDCS interface for that new instance and map the application roles to the users/groups that are defined IDCS. This is a one-time action you need to do. Subsequent deployments of the application will keep the mapping you did. From that point on, to do further mapping of IDCS groups and users to roles – use the IDCS interface and not the VB Studio interface.
Note that even if you define the same names for IDCS groups across different IDCS instance, the id assigned to a group in IDCS is not going to be the same. That is the reason that mapping of VB role to an IDCS group you did in one IDCS instance can't be transferred to the other IDCS on deployment. The mapping in the original instance is done using the group id and not the name, and that id doesn't exist in the other IDCS. You can see that mapping in your application's user-roles.json file.
In the video below we show you the full process of deploying and mapping an app to a new instance, including making changes to roles and redeploying.
We are developing the app on one VB instance (Dev) and deploying to another one (QA) which is using a separate IDCS.
After the initial deployment we go into the IDCS instance and map the groups/users to the app role. We then modify the app in VB Studio and redeploy – and as you'll see the mapping you already did are still there.
If you want to re-sync changes you did in IDCS into your application code check out this chapter of our documentation.