As of Support Pack 11 we have introduced the concept of Authorization Groups (Auth Groups) for the maintenance of Inspection configuration. This article provides an explanation of how this works.
- Understanding their Use and Impact
- Understanding how they are Created and Applied
- Assessing and Enabling Auth Groups
- Changing Inspections with Auth Groups
- Authorization Group Examples
Understanding their Use and Impact
Auth Groups have no direct impact on end-users use of BlueWorx. They exist solely for the benefit of exercising control of who can maintain Inspections and for what Plants and Technical Objects they can assign. These values are then used in the inspection determination logic (on device or SAP generation). Their use is entirely optional but once you have ‘turned on’ Auth Group use, all Inspection objects must be assigned to an Auth Group on next save.
Inspection Authorisation Groups can only be activated where BlueWorx Admin authorisations are active.
Understanding how they are Created and Applied
BlueWorx Administrators create the Auth Groups based on the Auth Group Strategy. The configuration options available to create Auth Groups are:
- Auth Group Name – self-explanatory
- SAP Auth Group Object - your SAP security team will create these and apply them to the appropriate Inspection Admin personnel using SAP Profiles
- None, one or more Maintenance Plants - these are used to limit which Plants you can apply in the Inspection Objects configuration. This Plant configuration option is new to SP11 and was in part introduced to support Auth Groups. If there are no Plants in the Auth Group then that means personnel with that auth can set up Inspections to apply to all Plants or selectively apply Plant - i.e. super inspection admin
- None, one or more Technical Object Types – these are used to limit which Technical Objects you can apply in the Inspection Objects configuration. If there are no Technolical Object Types in the Auth Group then that personnel with that auth can set up Inspections to apply to all Technical Objects or selectively apply to some Technical Objects - i.e. super inspection admin
Auth Groups, when in use, are applied to all the major BlueWorx Inspection objects, including:
- Inspection Groups
- Answer Groups
- Notification Templates
- Inspection Rules
Key Concepts - Very Important to Understand
- Of the objects listed above, it’s only within the Inspection configuration, in the Objects tab, where the Plant/s and Technical Object Type/s limited by the Auth Group are applied. In all other cases, the Auth Group is about limiting who can edit inspection configuration rather than how they are applied to inspections.
- Once you have assigned an Auth Profile to an Inspection it will blank out any Plant and Technical Object Types not assigned to the Auth Group you have applied.
i.e. if you have an Auth Profile that contains Technical Object Types: Car and SUV and leave the Technical Object Type config blank in an Inspection Object configuration, then, along with other config values, it will connect with Cars and SUV's. If the BlueWorx Administrator later adds Buses and Trucks to that Auth Group then, because the field is not specific, it will apply to Cars, SUV's, Buses and Trucks. The same goes for Plants.
Assessing and Enabling Auth Groups
The following are some suggested steps for reviewing/ designing and applying the auth group principles.
Step 1 - Understand the Concepts and Business Need
Read this article and understand what can be done using Auth Groups. Evaluate your operations and the required level of control for Inspections. Is the use of Inspection Authorization Groups, and it's inherent complexity, justified by the business benefits it will provide? If not then great, you don't need to go further at this time and can always revaluate later.
Step 2 - Preparation
Having worked out you want to use the Auth Group functionality you need to define a clear strategy for their use. This should define on what basis you're going to segregate authorizations and how that will be practically applied. Ensure that you take regulatory and safety type considerations into account.
Make sure that you keep the business involved and engaged in this process. Think about who in the business the auth groups will be allocated to - it's no use having a strategy with no one to execute it.
Step 3 - Define the Auth Groups
Map out what Groups you need and what Plants and Technical Object Types will exist in each.
Step 4 - Get SAP Authorisation Objects
Get your SAP administrators to create the required Auth Objects and allocate them to SAP User Profiles which are then assigned to 'test' personnel in your DVT/ TST system.
Step 5 - Check for Inspection Changed that's in Play
Check with the existing Inspection Administrators to check that anything in play won't be disrupted before you progress.
Step 6 - Turn Auths on Create the Inspection Auth Objects
In the BlueWorx Administration application, turn on Inspection Auth Groups and configure the groups you have designed in Step 3. along with the SAP Auth Objects created in Step 4.
Step 7 - Apply the Auth Groups
Now that you have the Auth Groups available we suggest that you provide access to all of these (for a limited time if necessary) to one individual for the purpose of the initial allocation of the Auth Groups to the various Inspection objects.
It's vital to understand that on applying an Auth Group to an object, it will ripple down and apply that Auth Group to any associated 'children' objects that do not have an Auth Group value. This ripple effect works as follows:
> Inspection Rule
> Inspection Group
> Inspection Question
> Answer Group
> Notification Template
Therefore if you have selected items that you want to specifically control by an Auth Group (for example Safety Question Groups, Questions, Answers, and Notifications, then ensure that you allocate the Auth Groups from the bottom-up for these items.
When you allocate the Auth Group at the Inspection level, you'll be required to maintain the Plant and Technical Object Type values, restricted by the Auth Group to the Inspections Technical Objects. So, for example, if an Auth Group is restricted to Plant 1000 then any Inspections with that Auth Group applied will have to maintain a Plant value of 1000 to all lines on the Inspection Objects tab. And conversely, if the Auth Group has no specified Plants and/ or Technical Object Types (meaning they are valid for all) then there will not be any required configuration for those values.
Changing Inspections with Auth Groups
You can change the Auth Group from one Auth Group to another. This action requires that the user doing the change has permissions to both Auth Groups. On making such a change the same ripple update action as described in the previous section will occur except that it will only change values in objects which do not have an Auth Group. Prior to Support Pack 12 Update 05 the change would ripple to all authorised Auth Groups which led to unexpected changes of data ownership.
Authorization Group Examples
You might have some Inspections in one or more Plants controlled by one Auth Group and Inspections used in another Plant controlled by others. This might be a division based on operations, geography, country, or regulatory requirements.
In this example, there are two Inspections Auth Groups, one for USA Plants and one for Canadian Plants. They have responsibility for all Object Types within their Plants. For a Sump Pump they create different inspections with different questions wholly independent from each other:
In the following example, two Auth Groups have been created. One for Passenger Vehicles and the other for Safety. The Safety Auth Group administrator has made a 'safety' Question Group and assigned a single 'safety' Question to it. The Passenger Auth Group Administrator has created an Inspection for daily vehicle checks and included, as the first Question Group, the Safety Group (and its Question).