Case Example: Adams Consulting Company

The following example of the Adams Consulting Company provides a working model of the System Role and Workgroup hierarchy, and illustrates the logical steps to take when implementing System Roles and Workgroups.

Please read the section on Users, System Roles, Workgroups, and Access prior to reading this case example.

STEP 1: Understand Employee Functional Roles

Prior to creating System Roles and Workgroups, it is imperative that you gain a through understanding of the functional role of each user within the company. If available, a company organizational chart can aid you in grouping individuals into functional groups.

By studying the Adams Consulting organizational chart illustrated above, note that there are two employees (C. Mackel and R. Welsh) whom are external consultants working on Project A in the Marketing Division. Based on their functional role and the projects they are working on, Adams Consulting determined that these employees only need access to the applications Workflow and Documents, and that the content be restricted to that related to Project A. In addition the company wants to restrict these users from creating Workgroups and limit their usage of Workgroups to those they are assigned to. This is accomplished by checking the External Status check box found on the Edit User Information page under Contacts (see the section on Adding Users).

STEP 2: Define System Roles

System Roles define the applications users have permission to use and what access level (privileges) they have within each application. All Synergy users MUST be a member of at least one System Role, otherwise they cannot logon to Synergy.

The first step to defining System Roles is to group users based on the applications they need to use and what their access rights are for each of the applications.

The next step is to provide a descriptive name for each of the System Roles. This name should describe the System Roles functionality. You may want to use a prefix to define the department, and a suffix of SR to make it easier to identify the group as a System Role. Utilizing a form such as the one below helps to clarify each System Role.

System Role Definitions for Adams Consulting Marketing Team

System Role	Members	Applications	Access Level
mrktg_External_SR	C. Mackel R. Welsh	Workflow Documents	4 4
Employee_SR	T. Holt, J. Hogg, S. Bowen, G. Smiley, B. McLean, J. Kemp, L. Smith, M. Jones, S. Koss, I. Japp	Start Page Workflow Contacts Documents	4 4 2 2
Manager_SR	J. Kemp L. Smith M. Jones	Start Page Workflow Contacts Documents	4 4 3
Directors _SR	T. Holt J. Hogg S. Bowen	Start Page Workflow Contacts Documents	4 4 4 4

The System Role mrktg_External_SR is comprised of the two external consultants working on Project A. This allows these two employees access to the applications Workflow and Documents, with an access level of 4 for both applications.

STEP 3: Define Workgroups

Workgroups define the content users have access to based on System Role membership. When defining Workgroups it is recommended that you first divide users into logical groupings based on the content they need to have access to.

The next step is to provide a descriptive name for each of the Workgroups. This name should describe what the content is related to. You may want to use a prefix to define the department, and a suffix of WG to make it easier to identify the group as a Workgroup. Utilizing a form such as the one below helps to clarify each Workgroup and the content each System Role (or user) has access to.

Workgroup Definitions for Adams Consulting Marketing Team

Workgroup	Description	Members (System Roles and/or Users)
Adams_WG	All members of Adams Consulting can access this content, except external consultants	Directors_SR Manager_SR Employee_SR
Executive_WG	Only directors can access this content.	Directors_SR
Management_WG	Only managers can access this content.	Manager_SR
mrktg_Project A_WG	Only managers and external consultants can access this content.	mrktg_External_SR Manager_SR

The Workgroup mrktg_Project A_WG provides access to content related to Project A. Since members of the System Role mrktg_External_SR are working on Project A, they have been made members of the mrktg_Project_A_WG Workgroup. In addition, managers who are members of the Manager_SR System Role must also be able to view Project A content. Given that Adams Consulting does not want the two external consultants to have access to internal company content, they are not members of any other Workgroup and their Contact record has been marked as External Status. Note that the Workgroup Adams_WG allows all internal employees access to general company content. The two external consultants are not members of this Workgroup.

STEP 4: Create User Accounts, System Roles, and Workgroups

Once you have developed your System Role and Workgroup hierarchy, you are now ready to enter your Users, System Roles and Workgroups into Synergy. Don't forget to give application access to the System Role, otherwise members of that System Role will not have access to the required applications. It is recommended that the System Role and Workgroup forms be kept up to date. They are an invaluable resource, making the process of maintaining System Roles and Workgroups an easy one.