Flex Item Protection

** NOTE: SUPPORT FOR THIS FEATURE IS NO LONGER INCLUDED WITHIN MAINTENANCE CONTRACTS. FOR ASSISTANCE WITH THIS TYPE OF FUNCTIONALITY PLEASE CONTACT US FOR OPTIONS.

The Flex Item Protection System provides functionality for locking down a Flex item to a defined “Protection Owner” and further allows for additional users to be granted read/write permissions as required.

This feature blocks access to Flex items from all users except those defined either as:

The “Protection Owner”: a people/group column field available to that list item.
A member of the “Protection SuperUsers” group, or
A Flex user granted permissions by the “Protection Owner” to either edit or view the item.

We recommend installing on a test server prior to installing on production. The install is performed on the WFE server which requires Farm Admin Rights.

Flex items are protected by checking the “Protected” Column field on the view/edit form of Flex item as shown below once the installation process is complete.

Note: The above fields are automatically added to the list but must be manually added to the forms.

How it Works

Review this list to learn how Flex Protection Feature works. When a Flex item (ie. Account, Opportunity, Project, Case, etc.) is protected all its child items will automatically be protected (ie. Tasks, Interactions, etc.). It is fast and effective but depending on overall system speed and a number of child items to be protected, it could take a few seconds on the first application.

When a Flex item (ie. Account, Opportunity, Project, Case, etc.) is protected, all of its child items will automatically be protected (ie. Tasks, Interactions, etc.). It is fast and effective but depending on overall system speed and a number of child items to be protected, it could take a few seconds on the first application.
Each time a protected item is edited (it doesn’t matter what has changed) the protection system will check the protection on all child items.
If something goes wrong on the first protection (eg. power failure) the next time the item is edited everything will be resolved.
If an Account is not protected, but one of its top-level child items is (ie. Opportunity, Project, Case, etc), and at a later date the Account becomes protected the new “Protection Owner” will overwrite all child items.
Removing protection also resets child items to their original unprotected state.
If the “Protected” field is checked, but the assigned “Protection Owner” field for that list item is blank then the item will NOT be protected.
Changing the “Protection Owner” and resetting the “Protection Field” cannot be done with one edit. First change the “Protection Owner” and then re-edit the item to set the “Protection” to true (checked).

Protection Feature Install Steps

Download CRMProtection.zip file from the location provided by LookOut Software which contains the following two wsp files:
1. CRMLogger.wsp: Required to both debug and monitor the Flex Protection feature and should be installed first.
2. CRMProtection.wsp: Contains the Flex Protection feature and is installed second.
Unzip the contents of CRMProtection.zip file provided to a folder on your WFE Server and make sure this folder either has a copy of the “stsadm.exe” or has access to it.
Use the following two scripts to install CRMlogger Web part– it uses the Global Deployment procedure. Always run your CMD window as Administrator.

stsadm -o and solution -filename CRMlogger.wsp

stsadm -o deploy solution -name CRMlogger.wsp -allow a deployment –immediate

CRMLogger Web Part can be found in Central Administration > System Settings> Manage Farm Solutions as being globally deployed, however, it is handled by SharePoint as a Feature which requires Activation.
To Activate CRMlogger Feature go to Central Administration > System Settings> Manage Farm Features and click the Activate button alongside the “CRMLogger Feature”.
When the CRMLogger Feature is “Activated” it adds the entry CRM Template’ as a new log level to diagnostic logging (ULS) and then, given Flex Protection’s activity, it can call methods and write to the SharePoint ULS logs with this specific level. When you examine the logs you can easily filter your custom calls.
You can also check that CRMLogger Feature is activated via the Central Administration > Monitoring > Configure Diagnostic Loggings as shown below:
If the CRMLogger Feature is not activated the ‘CRM Template’ entry is not available and every log attempt from the Protection Feature will fail.
As a secondary check you can you run one simple PowerShell script command inside the SharePoint PowerShell command line on your WFE Server:

Get-SPLogLevel | Where-Object {$_.Area -like "CRM template"}

It should provide a list result as:

If there are no results then the CRMlogger Feature is not installed correctly. If this is the case you can re-activate it (re-install or even re-deploy) and then do an IISReset.
Install CRMProtection Web part using the following two scripts:

stsadm -o and solution -filename CRMProtection.wsp

stsadm -o deploy solution -name CRMProtection.wsp -allow a deployment -immediate

As can be seen, in the screenshot below, deployment for these Web parts is Global so there is no need to target a particular site on your Farm.
Next go to Flex site – Flex sub-site level –NOT the Top Level site.
Go To Site Settings >Site Actions > Manage Site Features:

When the “Protection Feature” is deployed to an existing Flex site nothing visible will happen. In the background the “Protection fields” will be created on the designated lists and the protection code will ‘attach’ itself to Flex.

Activating the Protection Feature

Upon activation of the Protection Feature the following groups, settings and fields are automatically added to Flex:

A SharePoint Group called “Protection SuperUsers.” By default, there are no members in the group. Members of this group will have read and edit permissions on ALL protected items.
A SharePoint Group called “Protection SuperUsers Read Only.” By default, there are no members in the group. Members of this group will have read only permissions on ALL protected items.
An Advanced Flex Setting called “ProtectionEnabled” which by default is set to “False”. This setting determines the Flex Protection’s status. To start using the Protection Feature this Setting’s value must be set to “True.”
An Advanced Flex Setting called “ProtectionAccessUsers.” This Setting is blank by default. SharePoint Users and/or Groups that are added to this Setting will have permission to activate the Protected fields at the New/Edit item level.
An Advanced Flex Setting called “ProtectionEnabledListNameAndFieldDesignation” that contains standard Flex lists.
The following fields are added to all SharePoint Flex lists specified in the “ProtectionEnabledListNameAndFieldDesignation“ Setting.

Note: The above fields are added to the list but not to Flex forms (Display, Edit, and New). Modifying the forms must be done manually. (Refer to the “Form Editing” sections of this Guide.)

When debugging protection issues make sure that the ‘CRM template’ category is set to Verbose level so that all protection log entries are written.

Flex Protection Advanced Settings

The following Protection Settings must be configured as outlined prior to use.

Setting Name: ProtectionEnabled
Setting Value: True/False (default)

Change the value of the “ProtectionEnabled” Setting to “True” from its default state of “False”.

Setting Name: ProtectionAccessUsers
Setting Value: List of SharePoint Users or Groups (each on a separate line)

Add each user that will have the ability to protect items in this setting. Each value must be on a separate row. Value options are:

User’s login name, such as “domain/username”
User’s email address, such as.” johndoe@somecompany.com”
The name of a SharePoint Group or Active Directory Security Group
“All” [When this value is used, all users who have Edit permissions on the list will have access to the Protection System.]
“Blank Value” = No user will have access to the Protection system.

Notes:

To be able to protect items users also need to have access to SharePoint editing.
If any other mechanism is blocking the editing of form items (general permissions, custom feature), users will not be able to change the field ‘Protected’ and therefore, users will not be able to protect items.
If the user does not appear on this list Flex will ignore their attempts at protecting items.At this time, the field “Protected” may show a check mark but if the user isn’t on this list the field will be ignored.

Setting Name: ProtectionEnabledListNameAndFieldDesignation
Setting Value: List Name|Protection Owner

The default values for the Protection Feature are preloaded for the standard Flex lists:

Accounts
Contacts
Opportunities
Tasks
Email
Calendar Items
Notes
Projects
Case Management/Issues
Contracts
Interactions
Leads
Document Library|Folder

Following each list name is a “Pipe” ( | ) and then the Protection Owner is added (i.e. Account Owner for the Accounts List).

The exception to the above is the “Document Library|Folder” value. This value tells the protection system to include Flex Document Library “files”, along with all folders when items are protected.

Notes:

Protection functionality is available to all lists designated in the Advanced Flex Setting “ProtectionEnabledListNameAndFieldDesignation”.
When making changes to the “ProtectionEnabledListNameAndFieldDesignation” Setting, Flex Protection Feature must be deactivated then reactivated to ensure the protection fields are added to the lists
The changing or adding of “Protection Owner” field names does not require reactivation.
Setting values that have been incorrectly entered will be skipped by the Protection Feature.

Protection Groups

There are two SharePoint Permission Groups that are automatically setup.

The “Protection SuperUsers” group will override any restrictions placed on items. A user in this group will be able to assign protection to items for other users.

The “Protection SuperUsers read only” group can see all items they are given access to, but they are not allowed to edit the protected items. This can be handy in case you have an external audit of the system and you want to give full read access to all items in Flex on a temporary basis.

Protection Owner(s)

The “Protection Owner” is a Flex User who is granted the right to protect record items in pre-approved lists. It uses a People field that can also be used for filtering by [My] to create personalized lists.

There can be more than one “Protection Owner” on a Flex record item. See below for Scenarios.

Fictitious Team Example

Tom – Account Manager
Jane – Account Manager Deputy (defined in custom account field ‘Manager Deputy’)
John – Additional Edit User
Monica - Additional Read User

Scenario for Top Level Protection Record (Example: Account)

All users can add, edit and delete records if protection is not enabled.
Tom and Jane are granted the right to apply for protection.
Protection fields are enabled.
In all scenarios once an Account is protected John will have edit rights on the protected Account and Monica will have View rights.
Since all users are allowed to add, edit and delete records they can all add new child items (ie. opportunities, tasks, etc.) to protected Accounts.
Rights on child items (once added) can vary (see below).

Account|No Designated Protection Owner

This setting value is NOT RECOMMENDED since it can lead to unwanted protection setup.
Protection owner is not defined so both Tom and Jane can protect the Account.
Once the Account is protected both will lose access to it (!).

Account|Account Manager

User(s) defined in field ‘Account Manager’ (Tom) is Protection owner for the Account and he can protect the account.
Once the the Account is protected Jane will not have access to it.

Account|Account Manager, Manager Deputy

Both Tom and Jane are defined as Protection owners so they can apply for protection on Account.
After the account is protected both will have edit rights on it.

Account|Account Manager, Manager Deputy#E

Tom can apply for protection on the account. Jane as ‘Manager Deputy’ will have edit rights once Account gets protected.
The only difference from the last example is that Jane (even with edit rights on account) cannot change protection fields of Account so she cannot unprotect the Account or change additional user fields.
Jane can change all other fields, but protection fields will be reset to previous values upon item save.

Account|Account Manager, Manager Deputy#R

Tom is Protection owner so he can protect and unprotect the Account.
Jane will have only view permissions on it.
She can add a new child, but she cannot change the Account.

Scenario for Child Level Protection Record (Example: Task

The account is protected and Tom as Account Manager adds/changes a Task connected to it.
Child records inherit permissions from the top-level record.
If someone has a view or edit rights on the parent item he/she will have same permissions on each child item.

Tasks|No Protection Owner (Assigned To)

This setting value is NOT RECOMMENDED since it can lead to unwanted protection setup.
Example:Monica has view permissions on protected Accounts. Tom as Account Manager creates a new Task and assigns it to Monica.
Task protection is inherited from the Account –Monica will have only view rights and she will be unable to edit the Task.

Tasks|Assigned To
Tasks|Assigned To#E

Both settings have exactly the same result.
If a Task is assigned to Monica she will have edit rights on it.Since she has edit rights she can change the ‘Assigned To’ field value and she can reassign the Task to someone else.
In this scenario, she will lose edit rights upon saving and the new assignee will gain them.

Deactivating Protection Feature

To deactivate the Protection Feature, please take note of the following outcomes:

Items that have been protected prior to the deactivation process will still be protected until the item is opened
Flex Settings are neither deleted nor updated.
Protection Feature fields in each list will remain.
New items will not be protected.

Administrator Guide