Security Roles

Every workspace member in Ruddr is assigned a workspace security role. A workspace security role defines the set of privileges that members with that role are granted. A security role is comprised of various permission levels across the key sections of Ruddr:

• Workspace
• Company
• Opportunity
• Contact
• Member
• Client
• Project

We will look at permissions across Ruddr in that same order, but first let’s talk about the default, built-in roles that are present when a member first creates a workspace. Each Ruddr workspace comes with four built-in security roles. These roles are:

• Workspace Admin - The most privileged role in the workspace that has access to all information and settings. As explained below, this is a read-only role.
• Senior Member - This role is identical to the Workspace Admin role except that its members will not be able to access workspace settings or administer workspace members.
• Standard Member - The Standard Member can access clients and projects where they are on the project team. On those projects, they can view time and expense for all project team members. If this member is a Project Admin on a project, they can administer and approve time and expense for those projects. This role can view resource allocations for projects where they are on the project team. If this member is a Project Admin on a project, they can administer resource allocations for that project.
• Restricted Member - The default Security Role. A restricted role whose members can only access projects they are assigned to. Additionally, these members cannot view time or expense entries of other members, nor can they view invoices, bill rates, revenue, or profit.

As mentioned above, the Workspace Admin role is a read-only role but you can assign as many members as you like to that role. You cannot customize, rename, or in any way alter the Workspace Admin role. The other three built-in roles listed above can be customized to your liking, or they can be deleted. Also, you are free to create as many additional security roles as you like with the permission configurations that suit your organization. Additional actions that can be taken on security roles are:

• Set a Default
• Clone
• Deactivate
• Delete

​

View Security Roles

To view the list of current security roles for your workspace, click the Settings main nav bar option and then select the Security Roles menu option (Figure 1). From here you can edit or export your security roles. In order to access the workspace settings, your assigned security role must have the Administer all workspace settings and members permission. The Workspace Admin role is the only built-in security role that has this permission. To view or edit the parameters of a current role, simply click on the role name (Figure 2) to bring up the role settings.

​

Create a Security Role

To create a new security role, click the + button at the top-right of the security roles list. This will bring up the new security role drawer (Figure 3). Type in a name and optional description for the new role. Practice and Business Unit Scoping Several of the permission sections below let you scope a permission to the members, clients, or projects assigned to this member’s practice. If your workspace has the Business Units feature enabled, an equivalent business unit scope is available alongside each practice scope — for example, Clients assigned to this member’s business unit. The business unit scope behaves identically to the practice scope; it simply matches on the member’s business unit instead of their practice. For a member to fall within a business unit scope, that member must have a business unit assigned on their profile. This applies to the Member, Company, Opportunity, Contact, Client, and Project permissions described below, including time entry, expense item, invoice, and resource allocation permissions. For companies, opportunities, and contacts specifically, access is always evaluated against that record’s own Practice, Business Unit, or Owner — Ruddr never grants access to a record just because you have access to a related record. For example, being able to view a company does not by itself grant access to that company’s opportunities, and vice versa. The one deliberate exception is described under Company Permissions below.

​

Workspace Admin Permissions

When creating / editing a security role in the Security Role drawer (Figure 3), you will always see a Workspace Admin Permissions section (Figure 4). It is important to note that this section, while always visible, is unavailable to any security role in the workspace other than the built-in Workspace Admin role, which is why it appears greyed out in the image below (Figure 4). As a Workspace Admin with these permissions, a member can manage the workspace settings including the ability to administer workspace members.

​

Company Permissions

If your workspace has the Pipeline feature enabled, you will have a Company Permissions section available (Figure 5). These permissions determine whether a member can create, view, edit, and delete companies in the Pipeline area of Ruddr. Company, Opportunity, and Contact permissions are each independent rulesets — granting access to one does not grant access to the others. Create Company The first permission listed is Create company. When this permission is checked, the security role is automatically given permission to view all companies, including those assigned to this member’s practice or business unit and those this member owns. Company Access If the security role does not allow the member to create companies, the role can be configured to specify the level of view access permitted:

• All companies
• Companies assigned to that member’s business unit (when the Business Units feature is enabled)
• Companies assigned to that member’s practice
• Companies this member owns

Regardless of the above, a member can always view a company if they can view at least one opportunity belonging to it. This always-on rule is the one exception to the “own attributes only” rule described above, and it never grants edit access to the company — only view. Company Actions Once view access has been specified, the role can independently be granted Edit and Delete or archive permissions for companies, each with its own level of access:

• All companies this member can access
• Companies assigned to that member’s business unit (when enabled)
• Companies assigned to that member’s practice
• Companies this member owns

Edit and delete access are independent of each other and of view access — for example, a role can be given edit access to a broader or narrower set of companies than it can view.

​

Opportunity Permissions

If your workspace has the Pipeline feature enabled, you will have an Opportunity Permissions section available (Figure 6), structured identically to Company Permissions above. Create Opportunity The first permission listed is Create opportunity. When this permission is checked, the security role is automatically given permission to view all opportunities, including those assigned to this member’s practice or business unit and those this member owns. Opportunity Access If the security role does not allow the member to create opportunities, the role can be configured to specify the level of view access permitted:

• All opportunities
• Opportunities assigned to that member’s business unit (when enabled)
• Opportunities assigned to that member’s practice
• Opportunities this member owns

Opportunity Actions Once view access has been specified, the role can independently be granted Edit and Delete permissions for opportunities, each with its own level of access (all opportunities this member can access, those assigned to this member’s practice or business unit, or those this member owns).

​

Contact Permissions

Contact Permissions are always available, whether or not the Pipeline feature is enabled for your workspace — contacts and the ability to manage them are independent of Pipeline. Turning Pipeline on or off never changes who can create, view, edit, or delete contacts. Create Contact The first permission listed is Create contact. When this permission is checked, the security role is automatically given permission to view all contacts, including those assigned to this member’s practice or business unit and those this member owns. Contact Access If the security role does not allow the member to create contacts, the role can be configured to specify the level of view access permitted:

• All contacts
• Contacts assigned to that member’s business unit (when enabled)
• Contacts assigned to that member’s practice
• Contacts this member owns

Contact Actions Once view access has been specified, the role can independently be granted Edit and Delete permissions for contacts, each with its own level of access (all contacts this member can access, those assigned to this member’s practice or business unit, or those this member owns). Pipeline Activities Activities logged against companies, opportunities, and contacts (calls, meetings, notes, and similar entries) do not have permissions of their own. Instead, access to a record’s activity feed always follows the parent record it is reached through:

• If a member can view a company, opportunity, or contact, they can see its activity feed.
• If a member can edit that parent record, they can create, edit, and delete activities on it.
• The activity feed shown on a contact is always read-only, even for a member who can edit the contact, since contact activities are logged through the related company or opportunity rather than the contact itself.

Editing a record’s associations never silently drops one a member can’t manage: related records the member can only view remain attached as locked entries, while related records the member can’t view at all are hidden but preserved.

​

Member Permissions

The Member Permissions for a security role establish the access that a member has to time and expenses for another member or members. Additionally, this permission set controls access to other members’ resource allocations. There are two permissions “concepts” with regards to Time and Expenses and Resource Allocations:

1. Administer - This permissions concept enables View, Edit, and Delete permissions for time and expense entries and / or resource allocations. In addition, Administer grants permissions for approving time and expense entries, and submitting/un-submitting time and expense entries. Additionally, if your workspace has the Timesheets feature enabled, Administer grants permission to submit / un-submit timesheets.
2. View - This permissions concept enables read-only View permissions for time and expense entries and resource allocations.

In the Member Permissions section (Figure 8) a user can apply levels of Administer and/or View permissions for the scope of members against which a particular security role will apply. Leveraging this section (Figure 8), the following permissions can be applied to the security role:

​

Time and Expense

• Administer time and expenses for:
• View time and expenses for:

​

Resource Allocations

• Administer resource allocations for:
• View resource allocations for:

​

Client Permissions

The client permissions (Figure 9) control the user’s ability to access, create, edit, and delete clients, and to manage permissions on other actions for clients as well. These settings determine if the user can access all clients and projects in the workspace or just those where the user is on a project team for the client. By default (as shown in Figure 9), each Security Role grants access to any clients to which a member is assigned to that clients’ projects. Create Client The first permission listed is Create client. When this permission is checked, the security role is automatically given permissions to access the following:

• All clients
• Clients assigned to this member’s practice (Reference Custom Data for more information on practices)
• Clients where this member is assigned to a project

If a user has the right to create clients, that user is always allowed to view all clients in the workspace. Client Access If the security role does not allow the member to create clients, then the role can be configured to specify the level of client access permitted:

• All clients
• Clients assigned to that member’s business unit (when the Business Units feature is enabled)
• Clients assigned to that member’s practice
• Those clients where the member is assigned to a project

Selecting All clients will select the more granular options by default. Selecting Clients assigned to that member’s practice (or business unit) will select the last permission by default. Client Actions Once the level of client access has been specified for a security role, the next step is to specify the actions that a member can perform for clients that it can access. The remaining client permissions allow you can to specify whether or not the security role can perform these actions:

• Edit
• Delete or archive
• Administer published invoices
• Administer draft invoices
• View published invoices

For each of these permissions, there are two degrees of client access that are available (Figure 10). Selecting All clients that this member can access will automatically select Clients that are assigned to this member’s practice by default. Client invoicing permissions are related, in that the most graduated permission, Administer published invoices grants create and view permissions by default. Here is a breakdown of the permission inheritance for client invoices:

• Administer published invoices
  • Administer draft invoices
  • View published invoices
• Administer draft invoices
  • View published invoices

Note that as specific permissions are inherited, they also limit the clients that are accessible. For example, if Administer draft invoices applies only to Clients that are assigned to this member’s practice, then the View published invoices for these clients is limited to the same group of clients within that member’s practice (Figure 11). Affecting Project Permissions Assigning client permissions has a direct effect on project permissions assigned to the security role. Project permissions will be detailed later in this article, but it is important to note the project permissions that are selected by default when specifying certain client permissions:

• Delete or archive clients will grant:
  • Access all projects within an accessible client
  • Delete or archive projects
• Administer published invoices will grant:
  • Access all projects within an accessible client
  • View time entries and expense items on accessible projects
  • View bill rates on accessible projects
  • View revenue on accessible projects
  • Publish invoices for accessible projects
  • Administer invoices for accessible projects
  • View published invoices for accessible projects
• Administer draft invoices will grant:
  • Access all projects within an accessible client
  • View time entries and expense items on accessible projects
  • View bill rates on accessible projects
  • View revenue on accessible projects
  • Create and draft invoices for accessible projects
  • View published invoices for accessible projects
• View published invoices will grant:
  • Access all projects within an accessible client
  • View time entries and expense items on accessible projects
  • View bill rates on accessible projects
  • View revenue on accessible projects
  • View published invoices for accessible projects

Note, that much like the inheritance for client invoice permissions discussed above, corresponding project access is limited to projects for the clients allowed at the client permissions level.

​

Project Permissions

The project permissions (Figure 12) control the user’s ability to access, create, edit, and delete clients, and to manage permissions regarding time and expenses for projects as well. These settings determine if the user can access all projects in the workspace or just those where the user is on a project team for the client. By default (as shown in Figure 12), each Security Role grants access to any project to which a member is on that project team. The project permissions also control whether members will have access to potentially sensitive project data such as invoices, bill rates, revenue, and profit margin. Create Project The first permission listed is Create project. When this permission is checked, the security role is automatically given permissions to access the following:

• Clients where this member is assigned to project
• Projects where this member is on the project team

When the Create project permission is checked, the security role is also given permissions to edit the following:

• Projects where this member is the Project Admin

Lastly, when the Create project permission is checked, the security role is given permissions to view the following:

• Bill rates for projects where the member is the Project Admin
• Revenue for the projects where the member is the Project Admin

These are the minimum, required permissions for creating projects. Each project in Ruddr will have a single member designated as the Project Admin. Permissions within a project can depend on whether or not the member is the Project Admin of the project. Also, if manual time and expense approval is enabled for the project, the Project Admin will typically approve the time and expenses. On the team tab of the project dashboard, the project admin will have a green badge with a checkmark in the middle of it (Figure 13). Project Access If the security role does not allow the member to create projects, then the role can be configured to specify the level of project access permitted:

• All projects
• Projects assigned to that member’s business unit (when the Business Units feature is enabled)
• Projects assigned to that member’s practice
• Projects where the member is on the project team

Selecting All projects will select the more granular options by default. Selecting Projects assigned to that member’s practice (or business unit) will select the last permission by default. Project Actions Once the level of project access has been specified for a security role, the next step is to specify the project actions that a member can perform. The remaining project permissions allow you to specify whether or not the security role can perform these actions for projects:

• Edit - Edit the project details including the team, tasks, roles, rates, and budget. You can also limit which sections of a project the role can edit, as described in Edit Project Permissions.
• Delete or archive - Delete or archive the project.
• Administer published invoices
• Administer draft invoices
• View published invoices
• Administer time entries and expense items - Manage all time and expense entries on the project.
• View time entries and expense items - If a billable member does not have this permission, the member can only view his or her own time entries.
• Administer resource allocations - Manage all resource allocations for a project.
• View resource allocations
• View bill rates
• View revenue
• View profit
• Administer project health reports
• View project health

For each of these permissions, there are four degrees of project access that are available (Figure 14). Selecting All projects that this member can access will automatically select the latter three by default. Selecting Projects where this member is on the project team will automatically select Projects where this member is the Project Admin (as shown in Figure 14). Some project permissions are related, as project details have an intrinsic relationship with other project data. It is important to note the additional project permissions that are selected by default when specifying project permissions:

• Edit will grant:
  • View bill rates on projects
  • View revenue on projects
• Administer published invoices
  • Administer draft invoices
  • View published invoices
• Administer draft invoices
  • View published invoices
• Administer time entries and expense items will grant:
  • View time entries and expense items

​

Set a Default Security Role

Ruddr provides the ability for you to specify a default security role. This default is designated in the Security Roles section (Figure 2) as a black badge with a checkmark (Figure 15). When creating / inviting a new member in your workspace, you will need to specify a security role for that member. The default security role will automatically be assigned each new member that role. You can then specify a different security role, if desired. Setting a default security role allows you to define a “standard” role for most instances. To set a specific security role as the default, select Set to default from the menu for a specific role (Figure 16), accessible from the Security Roles section (Figure 2).

​

Clone a Security Role

Often times, it may be necessary to create a security role that closely mimics another security role. To assist with creating these types of closely-related roles, Ruddr allows Workspace Admins to clone existing security roles. You can generate an exact copy of an existing role and then have the ability to modify that new copy to fit the permissions needed. To do this, select Clone from the menu for a specific role (Figure 17), accessible from the Security Roles section (Figure 2). Give the role a new name (Figure 18) and click Save to create your new role.

​

Deactivate a Security Role

To prevent the future assignment of a security role to member, a security role can be deactivated. This will take the security role out of the list of available security roles to be assigned to a member. Deactivating a security role does not prevent the login of any users assigned to that security role, nor will inhibit their current permissions. While deactivated, a security role can be edited, cloned, or deleted. However, per the conditions outlined in Delete a Security Role, the Delete menu item will be disabled if any members are assigned to the security role. To deactivate an active security role, select Deactivate from the menu for a specific role (Figure 19), accessible from the Security Roles section (Figure 2). When deactivated, a security role is greyed out in the Security Roles section (Figure 20). Additionally, any deactivated security role can be reactivated at any time. To reactivate a deactivated security role, select Activate from the menu for a specific role (Figure 21), accessible from the Security Roles section (Figure 2). When activated, the security role is once again available for assignment to members.

​

Delete a Security Role

A security role can only be deleted when there are no members assigned to the role. In this case, the Delete menu item for a security role will be disabled (Figure 16) and the number of Active Users will be shown as more than zero (Figure 16). The Members section of the workspace settings displays each project member and their assigned security role. Additionally, you can filter this list by security role to find all members assigned to a particular role. Once all members have been removed from the security role (or reassigned to another role), that security role can be deleted. To delete the security role, select Delete from the menu for a specific role (Figure 22), accessible from the Security Roles section (Figure 2). When asked for confirmation (Figure 23), click Delete to finalize the removal of the security role.