Permissions service items/categories with application governance module installed

The entries in AccProduct and AccProductGroup with UID_AOBEntitlement are controlled automatically and exclusively managed via the AOBEntitlement. Therefore, the permissions are restricted.

Thanks Markus,

That is quite limiting when dealing with already existing service categories and service items. Implementing it in the customizer also blocks any customization.

If you decide to use Business Applications and Business Entitlements, the system automatically manages the corresponding service items and service categories via the business applications and entitlements and not on the items directly. This has been implemented to avoid manual misconfiguration.

What is the use case that you need to implement that is prevented by the current implementation?

My use case is as follows:

• We already have 1000+ requestable applications in the database that are defined or can be recognized by the service category.
• The AOB module provides a clean data model where we can formalize the available applications.
• We want to re-use the existing service categories, service items and shelves, and will override the functions AOB_Application_HandleCorrespondingObjects and AOB_Entitlement_HandleCorrespondingObjects in order to get rid of the creation of 'unique' service categories / service items.
  
  
• We will not use the web UI for the AOB module since we will not be migrating to the new Angular based web portal.
• Populating the AOB tables will be done by custom processes but we would like to keep the administration functionality available in Manager, and currently we can set the uid_aobapplication only for new service categories or if you are in the '_administrative' role forced by the customizer.

I read the documentation and dived into the processes but it seems that the application governance module pretty much expects a greenfield situation.

My use case is as follows:

• We already have 1000+ requestable applications in the database that are defined or can be recognized by the service category.
• The AOB module provides a clean data model where we can formalize the available applications.
• We want to re-use the existing service categories, service items and shelves, and will override the functions AOB_Application_HandleCorrespondingObjects and AOB_Entitlement_HandleCorrespondingObjects in order to get rid of the creation of 'unique' service categories / service items.
  
  
• We will not use the web UI for the AOB module since we will not be migrating to the new Angular based web portal.
• Populating the AOB tables will be done by custom processes but we would like to keep the administration functionality available in Manager, and currently we can set the uid_aobapplication only for new service categories or if you are in the '_administrative' role forced by the customizer.

I read the documentation and dived into the processes but it seems that the application governance module pretty much expects a greenfield situation.

Thanks for sharing the use case.

I've talked to some people and it should be possible to create a new application and assign it to an existing AccProductGroup to it if you do both in the same UnitOfWork in your code.

What I do not understand is the need to change the AOBApplication at the service category, Isn't that something that your process is doing? Why do you need to change it afterwards in the Manager?

I was creating some test data in Manager. In the final process it is not needed, we might have to hide the menu entry in order not to confuse the users. In my initial design I did want to keep the option of editing in Manager open but with the relevant columns being non-editable it will make sense to remove the menu items.