Configuring Web Product Restriction
Web product needs to be only accessible to contacts based on a set of criteria.
It does not matter which web product is flagged as restricted nor does it matter what the access criteria is. The web product becomes inaccessible to all contacts once the restricted flag is set on it. The only way it becomes visible is when a contact has a Web Product Restriction Override record.
For a contact to be granted access to a web product when it is restricted, a Web Product Restriction Override record is created with the contact and the web product lookup fields populated.
Examples of why this functionality would be used include: an event where only registration should be allowed to active members of a particular committee; a membership or product that can only be purchased by a select group of people. In each of these examples, all contacts who fit in the set criteria, need to have a web product restriction record created for that corresponding web product.
Generating Access Record Method(s)
The way to gain access will be to create a record in the Web Product Restrictions entity. This will establish the relationship between the contact to the restricted web product.
The specific criteria for granting or revoking access can change as the client’s business processes change. The WPR record can be created in any way the client needs. Here are a few examples but not limited to:
Workflow
Workflow activity
Custom plugin
Kingsway or another scribe job provider
Microsoft flow
Set up of the Web Product Restriction (WPR) Override Record
This entity is used to establish the relationship between the contact and the restricted web product. The contact field being populated identifies the “portal user” as having access to view a restricted web product. The web product field being populated identifies the restricted web product that the “portal user” can access. Both fields will be required to be populated on this record for the record to be saved as well as for the contact to be able to see the web product.
There is a flag on the web product that identifies if it will be restricted or not. When the restricted flag = YES then that web product will no longer be visible to any user in the portal. By default, all web products will be un-restricted (visible). Only web products that have the restricted flag set to yes will be restricted (hidden) in the portal.
The fields on the WPR record to be populated are:
Name: this is the name of the record and can be populated by the process that is chosen for the WPR creation.
Approved Contact: this is the lookup to the contact record that is approved access.
Approved Web Product: this is the lookup to the specific web product that the Approved Contact has access to.
To better help illustrate how this process works here is a flow diagram of the process:
User Scenario & Outcomes
Jon is able to access and view the restricted content on the portal because he has a Web Product Restriction Override record designating him as the approved contact and the approved web product associated with it.
Billy cannot see or access the web content on the portal in his scenario because he does not have a WPRO record designating him as an approved contact for the required web product.
In Sarah’s scenario, she is able to view the web product because it is not restricted and is visible and accessible to all users.
Source: David Carrion, Altai -https://altaisystems.atlassian.net/servicedesk/customer/portal/14/SAHIMA-48
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article