VPA Groups: Use Cases

It is easiest to understand how to use the VPA Groups feature by walking through specific use cases that illustrate how to use the VPA Groups feature.

In general sites will implement one way of restricting a particular type of data that is appropriate for their needs:

• For a service-provider scheme, tag all relevant tables with the Legal ID of each provider, and implement all VPA restrictions based on that.
• For adding a location restriction, restrict on a list of buildings.
• For adding a site restriction because you have a large list of buildings for each site, restrict on site using a bridge table to buildings.

Mixing and matching different types of restrictions must be done carefully, since all restrictions are combined to form one restriction, and this restriction cannot conflict with itself. You can combine orthogonal restrictions fairly easily – such as restricting on Legal ID and on Problem Type. However, if you are restricting by location, you should choose one scheme to implement, such as by building or by site via a bridge table. Functionally, this is all that is needed, since a building's assignment can be assumed by the site ID (if you are assigning on a site level) or by the building list (if you assigning on the building level). And technically, it's difficult to come up with different VPA restrictions on the same object (e.g. buildings) that can be combined without error.

The use cases are:

• VPA Groups Use Case: Building Code List - Assigning VPA Groups to Roles
• VPA Groups Use Case: Building Code List - Assigning VPA Groups to Users
• VPA Groups Use Case: Legal IDs (explicit query, role-specific VPA)
• VPA Groups Use Case: Bridge Tables (Sites example)
• VPA Groups Use Case: Bridge Tables (Service Contracts example)
• VPA Use Case: Unpacking Dependencies (Service Contracts example)
• VPA Use Case: Using a Hard Partition (Equipment table example)
• VPA Use Case: Using a Message Workflow Rule (Recalcuate Chargeback example)