Organization and Workspace Security Configuration

Summary
This document covers the security configuration for Organizations and Workspaces in the ClientSpace application.

Warning!

Role security is ubiquitous throughout ClientSpace. Therefore, deleting an existing role can have widespread, unexpected consequences! Removing a role can remove access to multiple parts of the application. Before deleting any role security, if you are not sure of the consequences, contact your customer success manager or application specialist.

Security Entities
Entities are the security objects used by the application to check what rights a user has to view, create or modify a system object. Entities are most commonly created by securing a Dataform or dataform field. Securing a dataform creates a Security Entity with the same name as the dataform, for example, if you secure the WhatDo dataform a security entity of gen_WhatDo is created (gen_zWhatDo for a custom dataform). In a similar way, securing a dataform field will generate a security entity for the field of dataformname_fieldname.

So securing the YouWant field on the WhatDo dataform will create a security entity named gen_WhatDo_YouWant. When a dataform or field is marked as secure, and that entity applied to a role, this item is unavailable in the system unless a user is either a Global Admin or a member of a role with at least View only rights for that security entity. In this way, you can apply very granular security to dataform objects. This security is also hierarchical, meaning if you secure a fieldset on a dataform, all of the fields inside the fieldset are secured by default, effectively hiding them unless the user has at least view rights to the fieldset. Careful application of Security entities and role security can make dataform configuration incredibly robust, allowing the application to have a customized look and feel for different groups of users without having a large number of dataforms.

Security entities can also be artificially created as part of the development process to secure items that are not generated by the system such as processes or custom objects like dashboards. The CRM entity, for example, is an object which provides a method for securing the Sales prospecting modules of ClientSpace. As with dataform field entities, the CRM_Phone entity controls rights to the Telephone field on the org and so on.

Similarly, business object security can be used to secure specific attributes of the system, such as the biz_clientservicecase_massupdate object that secures the mass update button for the client service case dashboard, or the biz_workflow_cm_accept that provides the user access to the Accept link on the Client Master page.

Another example is Incident_AllowTaskMaintenance. Ordinarily, only the Owner or Assigned To user can edit task fields. Adding the Incident_AllowTaskMaintenance entity to a user allows them to edit certain fields on a task even if they are not the Owner or Assigned To user.

Adding a dataform entity to a security role allows the administrator to secure dataform records in the following ways:

View: user can view the record (form or field) but is unable to add or manipulate the record.
Add:* user can add new dataforms of that type, or insert information into a field. Add rights apply anywhere in the system dataforms may be added, whether that is within a multiform list, from a dashboard or from the + symbol on a dataform link.
Edit:* user can adjust a dataform or field.
Admin: user has full rights to a dataform or field, inclusive of all other rights.

* Add and Edit

It is important to note that add and edit are not necessarily inclusive, meaning you can give add but not edit rights, or vice versa. In the role above the user can edit an existing Client Master form, but not create the original form. It is further important to note that dataform security only applies to dataforms on workspaces the user has access to, so unless you are a global admin, workspace security supersedes dataform security. You will only have access to employee dataforms for example for employees of workspaces that you have access to, allowing workspace security to work even outside of the workspace, such as on a dashboard.

Admin Security is powerful

Admin Security supercedes all other rights for dataforms to include special security such as the Row Level security for Secured case types. Do not apply admin rights to a dataform unless you are absolutely sure you want the role members to have Global Admin Access for that dataform.

Security Inheritence in NEXT

NEXT Entity security is Hierarchical, meaning that it is inherited from the parent object. This means that unsecured fields in a secured fieldset will inherit the security of the fieldset ie: an unsecured field in a secured fieldset where the user role has view rights will display the unsecured field as read-only. Users with Add rights to the fieldset will see the field as unlocked until it is filled, then the field will become read-only and so on.

Securing a fieldset with View rights affects all of the fields within that field set

ClientSpace Next has been enhanced to allow hierarchical security, basically any field within a fieldset inherits the security applied to the fieldset (to a point). Individual field security within the fieldset is still respected.

In the above example, Fieldset Test 1 has been secured with Edit rights, none of the fields within the fieldset have their own security so they inherit the security of the fieldset and are also secured with Edit rights.

Fieldset Test 2 has been secured with View rights and the luState field within fieldset 2 has also been secured, but with Edit rights applied.

Fields within Fieldset 2 inherit the Fieldset security unless they have their own security, so CheckTestToo and DateToo are View only, while luState which has it's own security can be edited.

It is important to note that there must be a minimum of view rights for a field or fieldset to appear on the form. In the following image, security has been flipped:

Fieldset Test 1 has been secured with View rights, none of the fields within the fieldset have their own security so they inherit the security of the fieldset and are also secured with View rights.

Fieldset Test 2 has been secured with Edit rights and the luState field within fieldset 2 has also been secured, but with View rights applied.

Fields within Fieldset 2 inherit the Fieldset security unless they have their own security, so CheckTestToo and DateToo are editable, while luState which has it's own security cannot be edited.

Best Practice

Draw a diagram of the dataform prior to adding security to it in order to map out how you would like the field access to occur. This will allow you to envision the different users that will need access to the dataform, and help you to better plan out how to architect the security and associated user roles.

Organization Security

The Security Action Item lists the users with access to the organization and what rights they have on the organization. The users and rights listed here can be added in a number of ways, including manual additions by the AssignedTo user, Departmental security additions, and Category Security additions. The badge displays the current user/role count with rights to the Organization. The rights list displays the security access for those users and groups. User rights options include:

View List: John can see all of Tim's orgs as well as his own, but if he attempts to open one of Tim's Org records the system will let him know he does not have access.
View: John can view Tim's orgs in the list and open any of Tim's orgs, but the fields are all read-only and John has no edit rights.
Edit: John can open and edit Tim's orgs as if they were his own.

Departmental Security

When a department is created, the system generates roles for Department Admin and Department member. Departmental security determines the access that departmental members and admins have to organizations created by other members of the same department, and range from None to Edit. Users in the Department Admin role additionally have full admin access to the Department Members organizations unless organization fields are specifically secured by adding organization field Security Entities to a role. For example, Tim and John are both members of the sales department. Tim creates a number of organizations and John opens the Org Search dashboard. What Member Org Access rights the Sales Members have determines what access John will have to Tim's orgs.

None: John doesn't even see the orgs or know they exist. If John attempts to create a duplicate of an existing org, the system will warn him a dupe exists.
View List: John can see all of Tim's orgs as well as his own, but if he attempts to open one of Tim's Org records the system will let him know he does not have access.
View: John can view Tim's orgs in the list and open any of Tim's orgs, but the fields are all read-only and John has no edit rights.
Edit: John can open and edit Tim's orgs as if they were his own.

Org Category Security

Org category security works in much the same way Departmental security works but is configured under System Admin > Security > Org Categories. Category security is configurable using the following parameters:

Organization Category: The configured security rights only apply to organizations of this Category.
Role: The configured security rights are shared by all members of this role.
Access: Determines what rights members of the configured Role will have for Organizations of the configured Category.

Org Category security dynamically updates organization security with changes to the associated Organization category. Changes made under System Admin > Security > Org Categories automatically propagate to the associated organizations with a related category. Changes include category, role, and access changes. If an Org Category is deleted, the security is removed from all associated organizations.

Workspace Users

The list of ClientSpace users that have access to a workspace can be found in the Workspace, in the Action Center menu > Users. Only these users and Global Admins will be able to access the workspace. As in the image above, the users in the list are pre-filtered for the current workspace. These users include Template workspace users for the template from which this workspace was generated as well as the associated organizations AssignedTo user and their departmental admin.

Client Master: Org Fields

The Client Master dataform is an amalgam of Organization data and gen_ClientMaster dataform information. Security for the Client Master dataform and fields is controlled by dataform level security entities, while security for the Organization data presented on the Client Master is controlled by the CRM security entity. Full CRM rights can be seen in Figure 1:

Figure 1 – Client Master with CRM Edit rights.

While removing the Edit rights from CRM will cause the Organization fields on the Client Master to appear 'Read-Only' –see Figure 2.

Figure 2 – Client Master without CRM Edit/Admin rights.

The rest of the fields on the Client Master dataform are controlled by Dataform and DataformField security entities, while the header action links are controlled via biz_workflow entities, such as biz_workflow_cm_activate. For detailed information on security entities and their application, refer to the Security Entities document.