What are Applicability Groups?

Issue/Objective

To understand applicability and applicability groups

Environment

PolicyStat systems with single or multiple sites

Procedure/Resolution

Applicability is a term used in PolicyStat that indicates PolicyStat site(s) where the document appears in the search results, or rather which sites a document APPLIES to. A policy can be applicable to one site or many. A group of sites a policy applies to is known as an Applicability Group.

An Applicability Group (AG) in PolicyStat is a location or bucket where documents are stored. The AG a document belongs to dictates the Applicability (hence the name, Applicability Group) and therefore the site(s) where the document is visible. This allows a single document to be applicable or appear across multiple sites while being centrally managed.
 

The websites act as the interface or portal where users access the application and search for or manage content. Sites have their own unique URL and represent an access point for an audience of users to specific content. For example, sites can represent a specific location or service within the organization and the content that applies to the corresponding audience for that location or service. Content could be local to only that site, meaning it is only searchable there, or it could apply to multiple sites as a part of the applicability network where the content appears across multiple sites. The sites will act as the front end for the users and the Applicability Groups control what content appears in the search results for each site.
 

Customers with multiple sites all have an applicability network which depicts the AG architecture. Below is an applicability network for a customer with 4 hospital locations. 
 

Those blue circles are each an AG but they are also linked to a single site. This means that any document that exists within one of those 4 AGs are only visible when a user navigates to one of those 4 sites. So when a user goes to rld-alpha.policystat.com they will only see polices that were uploaded or created inside the Alpha Hospital AG. The same goes for all the other AGs and sites. 

The above example is very simple and it depicts a customer that has no shared or system-wide corporate policies. So let us expand on the concept of Applicability Groups to take that into account. 

Below is the Applicability Network of the same customer but now this customer wants to have System-Level policies. This means they have policies that apply to and are visible across ALL their sites.  Users at Alpha Hospital will be able to view the same document as someone at Beta Hospital and vice-versa. The same document would also be visible to all users at Charlie Hospital and Delta Hospital. Applicability Groups help condense and streamline content that users at various hospitals should have access to. This is where Applicability Groups can help. 
 

 

   
In this diagram you can now see a white square System-Wide AG that is connected to the other 5 site specific AGs. This new AG is not linked to a particular site or URL, which means any document that exists within that System-Wide AG can be seen by any one of the other 5 sites. 
 

The System-Wide AG does not utilize a URL, but its contents are automatically propagated to any sites to which it is connected. If a user goes to rld-beta.policystat.com and a search is performed, any documents inside of the Beta Hospital AG as well as any documents inside of the System-Wide AG will be visible. By making use of this System-Wide AG, you can ensure that any policies that should be visible by ALL locations are only created and maintained once. This will help greatly in reducing duplicated and administrative overhead for identical policies that would have otherwise needed to be managed in multiple location. 
 

That new Corporate Site AG that was created is mandatory for us to be able to create this custom System-Wide AG. 
 

Finally, to expand one more time on these custom Applicability Groups; what if you had certain policies that only apply to the Beta and Delta Hospital, but not the other locations? You would not be able to place this document in the System-Wide AG as you don’t want the other locations to see it. But you also don’t want to manage two identical policies in two separate locations. AGs can help with that as well. Below is an Applicability Network with yet another custom AG created, ‘Beta + Delta AG’. 
 

It is similar to the System-Wide AG in that it is not site-specific like the blue AGs, but unlike the System-Wide AG, it is only connected to the Beta and Delta Hospitals. This means that any documents located in this new ‘Beta + Delta AG’ will be visible to users inside of Beta Hospital and Delta Hospital, thus solving the problem we had about what to do with documents that apply to both locations without having to have multiple copies of those documents. 
 

Please note that applicability is used to broaden visibility via Applicability Groups. Sites must exist to utilize applicability. Applicability cannot be used to restrict visibility within a site. 
 

APPLICABILITY GROUP RELATIONSHIPS 

When working with Applicability Groups, both the site-specific blue AGs and the custom white AGs, it is important to know what data inside of PolicyStat is linked to these groups. 
 

Documents 

As per the explanation above, you can see that documents do not exist in ‘SITES’ but rather to the Applicability Group. It just so happens that the blue groups are site-specific, so conceptually you can think of those documents belonging to those sites, but in reality, they exist in the Applicability Group. 
 

Users 

Users belong to the entire customer entity, but each user does get to choose a home site. They can change to other locations but by default when they log in, they will get taken to their home site meaning if John Smith’s home site is Alpha Hospital, and he logs in, he will get taken to rld-alpha.policystat.com. When he does a search, he will be able to see any documents that exist within the Alpha Hospital AG as well as the System-Wide AG. He can also change location to Beta Hospital. If he performs a search now, he will see documents that exist within the Beta Hospital AG, System-Wide AG and the ‘Beta + Delta AG’.  
 

Areas 

Areas belong to the entire customer entity but can be made visible/hidden at a SITE level as necessary. For example, you might have a ‘Diagnostic Imaging’ area but not all 5 sites have DI documents; perhaps Charlie Hospital does not. In this case, you can hide the Diagnostic Imaging area for Charlie Hospital. Click HERE for a more detailed explanation about areas. 
 

Approval Workflows 

Approval workflows belong to Applicability Groups, not only to sites. For example, you might have nursing policies in both the Alpha Hospital AG but also in the System-Wide AG. Those documents would both need a Nursing Approval Workflow, but the approvers required for System-Wide documents might be different than the ones required for the Alpha Hospital. In this case, you will need two workflows, one for the System-Wide AG and one for the Alpha Hospital AG. The same goes for the ‘Beta + Delta AG’. Documents there might need different people involved in their approval than documents from only Beta Hospital or only Delta Hospital. 

Because Approval Workflows need to be created and maintained at the AG level, you can see how this can quickly become very complicated to manage the more custom AGs you create. So only create AGs like ‘Beta + Delta AG’ when necessary. 
 

Permissions 

Permissions are assigned to users not necessarily by site but instead by Applicability Group.  Each site technically can be its own Applicability Group (if content should only be searchable at that specific site) but there may need to be elevated permissions given to specific users for various Applicability Groups that pertain to that site.  In the above example, a user may own content in Alpha Hospital but may need to create new content that applies “System-Wide” so they should probably be given the ability to create and edit content for the Alpha site AG as well as the System-Wide AG.  They potentially will have other options (Alpha+Beta, etc.) and depending on where content will live, they may need appropriate permissions for all Applicability Groups that exist for each site. 

Applicability is permission-driven. In other words, for users to see and assign applicability, they must be granted permission on their user account to do so. If the applicability field is not visible for a user on a document, the site they are on either is not part of a system with multiple applicability groups, the applicability group has not yet been created or the user does not have permissions to see or thus select from the existing created applicability groups. A site administrator can edit a user's permissions (giving edit permissions) to assign applicability to a document. Edit permissions must be given to a user's account for an applicability group to be seen in the selection drop-down of a document's properties.
 

Logos 

Logos are generally displayed by individual site. If a user is looking at content on Alpha Hospital, the user will see the Alpha logo on that content.  If a different user at Beta Hospital is looking at the same document from the Beta site, the Beta Hospital logo will appear on that document, even though it’s the same exact document. System-wide documents can take on the logo of the corporate site thereby displaying system-wide documents uniquely from site-specific documents.  

If a multi-site Applicability Group is applied to a document, the logo image for the site the document is viewed in will display if no document settings are specified for the Applicability Group. If document settings (the logo and the header field/date labels from a site)  are specified for an Applicability Group, the defined site logo will always display regardless of the site in which the user views the document. In other words, if a corporate logo is needed for certain documents the logo you want to use must already be in use on a site that is included in the applicability group. With this setting applied to the group, the defined site logo for the selected site will always display regardless of the site in which the user views.  For more information on adding a specific logo and custom labels from a site see How do I edit or modify Applicability Groups?

Additional Information

Applicability groups can be created and modified by administrators, but they cannot be deleted.  For more information see How do I edit or modify Applicability Groups?

To learn more about creating Applicability groups, see How do I create new Applicability groups?

For more on selecting an Applicability for a policy, see How Do I Select Applicability?