Introduction
Almost every page in Connections can have its security customized. This can range from who can read the page to what they are allowed to do there as well. But with the ability to do mostly anything you want with granting or revoking access to pages and their modules, there can be a bit of a learning curve.
Note: Administrators have access to all areas of the application regardless of security settings. This includes organization and individual dialog pages.
Most pages in the application will have a security icon at the top of the menu on the right side of the page. This link will display the security settings for the current page and may have a separate tab for default security on items that can be created for the current page. Such as default project security for the department or for an individual the default security for a new individual metric.
Page Security will define the access to the page you opened the security settings from.
Default Security defines a security template that new pages/items will be created with. This does not change the existing security on any of the pages that have already been created.
Each security entry defines a role, user, or security group with each of the 5 security permissions for a specific security section. Every section should have an Everyone entry which applies to everyone in your organization.
Access Roles: There are 5 security roles for each entry. Each entry consists of a group or individual and an associated access role with optional create permissions.
-
Reader: The user/group can read the page.
- Example: Giving Reader access to a department dialog to department members so that everyone in the department can see what went on during the meeting.
-
Editor: Same as Reader but can also edit the page and anything on the page that doesn't have separate security.
- Example: This would be common for anyone who needs to interact with a page but does not manage access to the page such as a project Member.
-
Full Access: Same permissions as editor, but has the ability to modify the page security and default security associated with the page.
- Example: Grant full access to a user/group when they need to modify permissions to a specific project/metric beyond the typical defaults.
-
Denied: The user/group cannot read the page. This will override any permissions granting access to the page that may be from other groups or entries that apply to the specified user/group.
- Example: Add a Vendor security group to department dialog security with Deny access to prevent users in that group from viewing department dialogs even if their department role would otherwise allow it.
-
Not Set: The user/group is neither granted nor revoked access from this entry.
- Example: Use this to not give the Everyone entry access to a dialog and allow only that Given Individual and their Reports To.
Create Security is separate from the regular page security roles listed above. On pages such as the organization, departments, projects, and individuals there are additional pages that can be created on each. In the example below, the Organization Leader can create Departments, Projects, Users and Metrics for the organization and the Organization Editor can create Metrics, Dialogs, and Commitments.
Note: The person who creates an item in Connections, such as a department, project, metric, or task will have implicit Full Access to that item even if it is not listed on the page's security settings.
Included Security Groups: These are the built-in security groups that you will mostly be using to configure access to pages in Connections.
- Everyone (Organization Member): Includes absolutely everyone in the organization.
- Organization Editor: Can create and modify content across most pages (excluding individual connections). This role works well for managers who need high access but not admin privileges.
- Organization Leader: Has full access to organization-wide settings, including promoting others to leader/editor roles and making system-level changes. This role is closest to being an administrator.
- Department Member: all people that are listed on the Individuals tab for a department. Gives reader access to most of the department.
- Department Editor: Can create and edit all department content but cannot assign security roles.
- Department Leader: Full access to their department's content and permissions management such as promoting others to Department Leader/Editor roles.
- Metric Owner: All people on the owner's list of the metric. Usually gives full access to the edit the metric and its thresholds and values.
- Person Responsible: All people on the responsible list for the task. Gives access to edit and delete the task.
- Given Individual: The person whose page this is. Has full access to their own page.
- Reports To: The direct person(s) this individual reports to.
- Reports To (and above): Includes anyone your direct manager reports to all the way up the reporting tree.
- Project Roles (Sponsor/Leader/Member/Consultant): the four default roles for the project team. Each can be configured separately for each project.
- Specific User (ex: Dan Brown): Security applies to only this person. Useful for special exception security.
- Custom Security Group: A group created by your administrators that can be added to any page. The list of people that belong to these groups is managed on the security page for the organization under the Security Groups tab. These security groups are intended to cover cases where the roles above are not sufficient to define a role/group of people and what their security needs are.
An individual in Connections may meet multiple criteria within a security section. In such a case the security will be combined through all roles that apply to the individual. The individual may be able to read the page via the Everyone settings and then have the ability to Update and Delete from the Department Editor security group. In the case of a Deny being set on one of the applicable entries for the individual, it would override any security set from the other roles, and that individual would not be able to access the page.
How Role-Based Security Works (Best Practices / Intended Use)
In Connections the majority of your security will be covered by your role or association to the content. In the table above it is outlined each of types of content in Connections are and which roles are given what levels of access to those pages by default. These settings can also be customized to meet your needs.
Most user permissions are determined by either:
- Their role on organization or department pages, and
- Their association with specific items, such as being an owner of a metric, responsible for a task, or part of a project team.
The built-in security roles automatically assign default access levels based on a user’s relationship to a given page or object. These defaults can be customized, but they serve as a strong starting point.
Organization Roles
- Organization Leader Has full access to organization-wide settings, including promoting others to leader/editor roles and making system-level changes.
- Organization Editor Can create and modify content across most pages (excluding individual connections). This role works well for managers who need high access but not admin privileges.
Department Roles
- Department Leader Full access to their department's content and permissions management.
- Department Editor Can create and edit all department content but cannot assign security roles.
-
Department Member Read-only access. Can engage with department content if granted additional associations like:
- Task responsibility
- Metric ownership
- Project team membership
Content-Level Access via Associations
Users may also gain permissions based on their relationship to specific content:
- Task Responsible: Full control to edit/manage assigned tasks
- Metric Owner: Can adjust values, thresholds, and remove metrics
-
Project Roles:
- Sponsor: Full access to the project and related items
- Leader/Member: Collaborate on tasks, metrics, and dialogs
- Consultant: No additional access by default
Setting Up a New Employee
Here’s a recommended setup flow:
- Add a New Individual Go to the Organization’s “Individuals” tab and add the user.
- Assign a Manager In the “Edit Individual” modal, use the dropdown to set their manager. This activates the Reports To permission so the manager can view their page and dialog.
-
Assign Department(s) In the user's “Departments” section:
- Choose Department Member for read-only access.
- Choose Department Editor if they need to create/edit content.
- Choose Department Leader if they need to assign roles and manage department security.
-
Assign Organization Role (if needed) If they’ll manage organization-level content like projects, metrics, or dialogs:
- Use Organization Editor for creation/edit access.
- Use Organization Leader for system-wide permissions and role assignments.
Example: Dave in HR
Dave is a manager in Human Resources and needs to manage users and HR content within Connections:
- Assign him the Organization Editor role so he can add/edit individuals organization-wide.
- Add him to the Human Resources department as either a Department Leader (to manage roles) or Department Editor (to edit content only).
- Add Dave's manager(s) so they gain the Reports To permissions to view his individual dialogs.
The rest of his permissions should be assigned when he is added on a metric, project or task.
Security Inheritance
Below is the overall hierarchy for security in Connections. List items in bold have their own security pages. The rest of the list items inherit their permissions from the page they can be found on. For example, organization dialogs get their permissions from the Organization Dialog defaults section on the Default Security tab for the organization security page.
Note: Anything on the page that isn't listed on this security hierarchy, such as Related Links, is included in the page security for the page where it resides.
-
Organization
- Organization Metric
- Organization Dialog
- Organization Dialog Task
-
Project
- Project Metric
- Project Task
- Project Dialog
- Project Dialog Task
- Organization Commitment
-
Department
- Department Metric
- Department Dialog
- Department Dialog Task
-
Project
- Project Metric
- Project Task
- Project Dialog
- Project Dialog Task
- Department Commitment
-
Individual
- Individual Metric
- Personal Task
- Basic Role
- Basic Role Task
- Individual Dialog
- Individual Dialog Task
- Individual Commitment
- Personal Development Goal
- Individual Performance Report (The individual and people up the reporting tree from the individual can view this report)
At the top of the security hierarchy are the default settings for the whole organization. Your administrators can define at the site level what security is added to newly created Departments and Individuals by default. Anything not specifically mentioned on the list above such as Related Links is lumped in with the page itself and shares the same security as the overall page.
When security is changed for descendants/sub-pages, such as changing project metric security on the project page, the existing descendant's security is not changed. The update made for project metrics will define the default security settings for all metrics created afterward on that project. In order to pass these new settings to existing metrics the security settings would need to be propagated to those descendants.
(security propagation not implemented yet in the application interface) Since the organization dialogs do not have their own page you do not need to propagate the changes in order for them to take effect. This means that all bold security items in the list below will require propagation from the item above them to update existing security.
Another common goal is to give individual dialog access to the individual's manager. By default, this is the case that the Reports To role has access to read the Given Individual's dialogs.
Comments
0 comments
Please sign in to leave a comment.