Considerations for Group VPAs

The Archibus core automatically applies the VPA restriction to standard datasources. However, applications and deployments are complex and often employ non-standard datasources, such as datasources that contain hand-coded SQL or datasources implemented in Java. VPAs may need to be applied conditionally. When deploying VPAs, you may wish to reviewyour deployment for any of the following conditions and adjust the datasources that rely on partitioned data accordingly.

Single-customer applications

The core features do not automatically apply in several conditions, and for these conditions, you must adjust or relax the VPA restriction as appropriate.

Condition	Consequences to be aware of	Approach
Views that have hand-coded SQL restrictions	The Web Central core does apply VPA automatically if the datasource has a VPA table. Because the type of applied VPA restriction is not known in advance, hand-coded SQL restriction queries may not be compatible with the VPA; in such cases, the view may fail to load. The Web Central core does not apply the VPA restriction automatically if the datasource does not have the VPA table, and so the view shows all data not the VPA restricted data.	Follow the approach outlined in this topic to apply the VPA for the current user: VPA Restrictions and Custom Data Access
Views that have hand-coded SQL	The Web Central core does not apply the VPA restriction automatically, and so the view shows all data not the VPA-restricted data.	Follow the approach outlined in this topic to apply the VPA for the current user: VPA Restrictions and Custom Data Access
Views that have pick lists that are not useful if a restrictive VPA is applied.	Some views (such as move views with building pick lists for moving employees between buildings) are not useful if a restrictive VPA is set (such as a VPA restricting access to the one building whose data they maintain). These views should assume that if a user has access to the application, they have access to these basic pick lists.	Add `applyVpaRestrictions="false"` to the datasource in the .axvw as appropriate.
Workflow message rules that need to access more data than the current user has access to.	The Web Central core does apply the VPA to the record sets within workflow rules, which then does not calculate all the data it should for this condition. An example is PM Scheduling, as this action needs access to broad information to create the work schedule, yet the user who can invoke the PM Scheduling workflow rule may be restricted to actually seeing only the data for one site or building.	Tailor the VPA query for this rule per the technique described in this topic: VPA Restrictions and Custom Data Access. (In this case, the VPA is tailored for the program to execute only this one WFR. These permissions do not extend to the user, who cannot see any additional data.) Alternately, define a VPA role that has rights to execute this action, and have the code reference that role. For example: `new FieldFormula("fl").setAssignedRestriction("fl.prorate_remain='FLOOR' AND " + ${sql.getVpaRestrictionForTableAndRole('fl','SP-MGR','')} ).calculate( "fl.area_fl_comn_ocup", "fl.area_remain + fl.area_fl_comn_ocup"`
Views that display pre-calculated values.	Because the values are pre-calculated -- typically by a scheduled WFR -- without regard to different users and different VPAs, the view cannot filter data by VPA.	Limit access to views to just those users who can review all pre-calculated data --or-- pre-calculate different sets of data for different user roles. See User Help topic, Real Property / Strategic Financial Analysis / Adding VPA to the Financial Analysis Console for example recommendations.

Multi-customer applications

Any view or workflow rule that shares tables between different customer organizations or service providers (that is, separate legal entities) must be reviewed and edited to make sure that it applies VPA's.

Condition	Consequences to be aware of	Approach
Views that have hand-coded SQL restrictions	VPA may not be able to merge the automatic VPA restriction with the hand-coded one.	Add a hard partition legal ID restriction on the affected tables. Review and test the VPA restriction.
Views that have hand-coded SQL	VPA may not be able to merge the automatic VPA restriction with the hand-coded SQL.	Add a hard partition legal ID restriction on the affected tables. Review and test the VPA restriction.
Views that have pick lists that are not useful if a restrictive VPA is applied.	Per the above, these restrictions may need to be suspended for certain application views.	Add a hard partition legal ID restriction to these datasources.
Message rules or scheduled rules that recalculate all data.	Per the above, for the standard Archibus product, these rules have tailored the VPA for the rule itself so that it calculates all data, assuming that all data belongs to one customers. However, rules like Metrics recalculation or PM Scheduling must apply a per-customer VPA to the rule to keep calculations and results from different customers separate.	Adjust the workflow rule to apply the hard partition legal id to the restriction controlling which data to delete and then recalculate.
Field formulas and field operations recalculate all data.	Field formulas and field operations do not apply the VPA and recalculate all data.	Adjust those workflow rules that use field formulas and operations (e.g. `AllRoomChargeback.java`) to add in the VPA restrictions, e.g. with the `.setAssignedRestriction()` method.