Adding Teams

Objective

After completing this lesson, you will be able to describe how to create groups, team members, assignments and restrictions.

Manually Adding Project Groups and Assigning Project Group Roles

The Team tab to edit the team members is displayed.The Team Members section with highlight on Add Group.

The Group column lists the project groups that are part of the project team. Each project group can have roles assigned to it, which will allow members to perform certain actions within the project over and above those already granted to them via their specific system group membership. Project groups are used to designate which users or groups are assigned to a particular task within the project.

You can add project groups by clicking on the Team tab and selecting ActionsEdit. Then click Add group button. On the subsequent screen, provide the project group title, and assign roles to the project group. The roles allow the members of the group to perform actions in the application, such as create a project. Once the group is added to the team, you may select members (i.e. actual users) for the group but generally it's done within the project and not within the template.

The Roles section is highlighted on the Project Group Details page.The Choose Values for Roles section is displayed.

Roles are permissions that are assigned within a project. This is how users can be given the ability to edit some projects, but not others. Since roles give permissions to members of the project groups that are assigned those roles, it can impact user licensing. For example, any user placed into a group with the role of Project Owner will occupy a user license. Roles are optional and do not need to be assigned to a project group unless needed.

An optional step after you have defined the project groups and corresponding roles is to assign system groups to the project groups. This should be done only if there are roles that should be assigned to the same system groups for all workspaces that are created from the template. For example, as an administrator, you might want to create a project group called Administrators and a system group to that project group so you will have access to all projects created using that template. It’s also possible to assign specific individuals to the project groups at the template level, but it’s not recommended. Because people get promoted, leave the company, etc., it could become burdensome to maintain the templates. In many situations, it is not necessary to assign anyone to the project groups since that job is intentionally delegated to the project creator and is usually determined on a project by project basis. Groups should only be added to templates when they are auditors or executives that need visibility into all projects.

Certain system groups or permissions are granted special abilities when they’re added to the team of a project. Examples of these are Customer Administrator, Project Administrator, and Contract Administrator. When users that have these permissions assigned to their User ID’s are assigned to the team of any project, they are automatically granted owner rights within that project because of the system level permission. System level permissions are groups that are assigned to users when they are created and are a part of their user profile. Roles are project specific and do not grant those same permissions site wide. This is how the system allows for you to have a user edit one project without the ability to edit all projects they are on the team of as in one case they might be an auditor and in the other, a stakeholder who will actively work on the project.

Implementing Advanced Options for Project Groups

  • Can owner edit this Project Group – This is a yes or no question that allows you as the administrator to decide whether or not users who create projects using this template will be able to modify the users in this group.
    • There is no way to change this setting in a project when set at the template so new groups will need to be created should an additional team member need to be added to the group.
  • Restrict Additional Members – This is an optional feature that allows you to restrict the users that can be added to a project group. This can make it easier for project owners to add members to project teams by filtering the users shown in the chooser.

Populating Project Group Members

  • Add Project Groups
    • Collection of users that will be involved in the project
  • Assign Roles to Groups
    • Provide users in groups with necessary permissions for the project
    • Roles are optional and do not need to be assigned to a group unless needed
  • Add Members to Groups
    • Specify individual users or groups that will be involved in the project
    • Never add individual users to a template’s team, instead tie templates to custom groups to allow easier adjustment of members
    • You can define the members of project groups by:
      • Manually adding users or groups on the template’s Team tab
      • Creating team member rules or buyer category assignments to dynamically add users or groups during project creation
      • Leaving the group empty in the template and allowing the Project Owner to add members during project creation

Continuing in the creation process of a template, the next step is to define the team members that will be associated with the project. The first step to defining the team in a template is to add the necessary project groups. Project groups are collections of users that will be involved in the process. Out-of-the-box SAP Ariba templates will contain some project team groups by default. These include Global Observers, Project Owner and various others depending on the type of template being created. As the administrator, you can decide to use these groups or delete them and create your own.

To add a new group, from the Team tab of the template click ActionsEdit and then click the New Group button. You will then see the Project Group Details screen where you will need to provide the following information:

  • Title – This is the name of the group. Be sure to be descriptive when naming a project group. This helps end users identify what the group is for.
  • Members – This field is not yet available to be populated. The system requires that a group be created prior to adding users to it, thus you will assign groups later.

Describing Team Member Rules

  • Team Member Rules use a Microsoft Excel file as a lookup table to determine which member (user or group) to add to the project team.
  • Multiple conditions can be included for each team member rule, as needed.
  • Help you to standardize the template creation process.

Team Member Rules consist of a multi-tab Microsoft Excel file in order to set conditions on team members being added to the project team. This file includes three reference tabs: Instructions, Field Names and Project Groups, and a Team Member Rules tab to be completed. The file can be used to conditionalize team members (individuals or groups) based on field selections. Multiple fields (columns) and multiple rules (rows) can be used as needed. This allows conditions to be built such as… When Region USA is selected add member Steve Smith to project group Contract Observers. Another row could be used to build… When Region APAC is selected add member group APAC Users to project group Contract Observers.

Use multiple columns of fields to add advanced or various conditions. When Region USA and Commodity Footwear are selected. If you want to the rule to apply to all possible values for a column an asterisk (*) may be used as a wildcard for rules that do not use an individual field. If you want the rule to apply to a range of values for a column, use the tilde character (~). Range expressions are inclusive of the lower boundary but not the upper boundary.

If you add fields or project groups to the template, you can re-export the team member rules workbook so it will contain the updated information.

It is a best practice to add groups as members, not individual users as much as possible. This provides more flexibility for changes moving forward (changing teams on published workspaces).

Note

SAP Ariba Best Practice: Use Team Member Rules to add custom groups as conditional team members in order to limit future workspace and template updates due to team changes.

Creating Team Member Rules Templates

NameDescription
InstructionsA set of instructions for using the team member rules file.
Field NamesA list of the full names of all of the template's current fields in dot notation.
Project GroupsA list of all of the template's current project groups.
Team Member RulesA worksheet where you create team member rules by entering values in columns.

Use the information on the Field Names and Project Groups tabs to create team member rules on the Team Member Rules tab.

The TMR template contains a workbook tab for each area in the slide above. Three of the four tabs are for your reference and won’t need to be populated with information. The instructions tab contains some brief instructions on how to populate the file.

The Field Names tab will contain a list of all of the header fields that are a part of that project type and available to be used in the TMR file. Fields become available for use in the TMR when they are made reportable. If you are working with an existing TMR file, any header fields that have been added after the TMR file was first configured, the new fields won’t be available in the list. The field names exist on this tab mostly so you have a reference to know what to place into the Team Member Rules tab of the workbook. If a field doesn’t show there, you can export a new TMR file from the Team tab of the template to see the name of the field. If you know the name of the field, it is not essential that it be listed on the Field Names tab. The Field Names tab is especially helpful when referencing questions from the Supplier Profile Questionnaire in the TMR file.

Defining a Team Member Rules Example

An example displaying how to define a team member rule.

In this example, there are two Project Fields being used in Columns A and B – Regions and Client (Department). Line 2 says ‘For any department (the asterisk in A2), when the region is USA, add the Contract Team USA group to the Contract Observers project group. When a user creates a project, if they select USA as the region, then the Contract Team USA is automatically populated on the team tab in the Contract Observers group. In Row 2, we are adding John Smith to the Contract Observer group, rather than a user group.

When creating these rules, any field where the value doesn’t matter, you can use an asterisk. This serves as a wildcard and says that any value makes this particular rule true. If you add a User to the team, then the Group (Column D) will be empty. Instead, you’ll provide the username (Column E) and the PasswordAdapter (PasswordAdapter1 for all Enterprise Users).

Creating Team Member Rules

When the system matches values to add team members, the following criteria for each row in the rules file is used:

  • All Values in field name columns must match the template project’s values for those field or the row is not considered a match and is ignored
  • Wildcards (*) and empty column values always match
  • Hierarchical field matches can be matched by child field values

Create Team Member Rules:

The step-by-step process to create or open a project template is displayed.
  1. Create or open a project template.
  2. Download a team member rules template that contains the project template’s current project groups and field names. On the template’s Team tab, choose ActionsDownload Template (under Team Member Rules).
  3. Save the team member rules file template XLS file to the location of your choice.
  4. Edit the team member rules file template to create team member rules. Enter values in columns on the Team Member rules sheet according to the following table.

Hint

If you want the rule to apply to all of the possible values for a column, enter a wildcard (*) in the column or leave it blank. This allows you to add multiple rules to the same TMR file so for administrative purposes, there is only one TMR to manage. If you want the rule to apply to a range of values for a column, use the tilde character (~). Range expressions are inclusive on the lower boundary but not on the upper boundary. For example, to create a rule that applies to every value of 1000 and over, enter 1000~; to create a rule that applies to every value from 0 to 3, enter 0~4; to create a rule that applies to every value below 1000 (but not 1000 itself), enter ~1000. You can only use range expressions in rules for numeric fields.

Describing Team Member Rules Components

TeamDefinition
Field_NameRepresents the names of fields in SAP Ariba; the values in this column match the values in a project created from the template. The template adds the users or groups in the row to the project group or makes the specified user the default project owner.
ProjectGroupThe name of the project group to which you want to add users or groups.
UserThe user names of the users you want to assign to a project group.
PasswordAdaptorThe password adapter associated with the user name or users names. Used to distinguish between users that have the same user names.
GroupThe name of the global user group that you want to assign to the project group.
OwnerIDThe user name of the default project owner for all projects completed from the template.
OwnerPasswordAdaptor​The password adapter associated with the owner’s username.

Adding Team Member Rules to a Template

  • Team Member Rules are uploaded to the Documents or Team tab.
  • Tasks cannot be created for team member rules file documents or the conditions set on them.
  • There’s no limit to the number of team member rules files you can add to a template.
    • Each team member rules files that is uploaded to a template adds to the total set of team member rules the template uses.
    • To make modifications to an existing team member rules template, make the edits on a file on your local computer and upload the file as a replacement document.

The Team Member Rules document can be downloaded several ways from a project. If there is already an existing TMR file in your template, you can download it from the Documents tab by clicking on the document title and choosing Download. This will download your current team member rules file and you can add/modify any rules that are in the file. When you are ready to re-upload the document to the template, you can click the title of the existing TMR file again and choose Replace Document. This will ensure that the document is uploaded as a TMR file, rather than a regular document.

If your template does not already have a TMR file, you will need to download a template. You can download a new TMR file template from the Team tab of your template. Click ActionsDownload Team Member Rules to download a template you can use to start configuring your TMR.

You can also re-use TRM files in multiple templates. If the same fields and the same rules apply, it is possible to upload the same TMR file in multiple project templates.

When working with TMR files, it is helpful to enable DFS as it makes it easier to update the TMR files since you don’t have to save the document to your computer and then upload it into the project. With DFS enabled, the system will know you’ve made a change to the document and it will automatically prompt you to update the file in the template.

Validating Team Member Rules

  • Team Member Rules files are validated by publishing the document.
    • The file should be published once the rules have been finalized and in order to check for technical errors.
  • Edits made to a published Team Member Rules file will only apply to project created from the republished template.

    The edits are not retroactively applied to existing projects.

Once you’ve configured your TMR file and have uploaded it back into the template, you can use the Create My Test Project functionality to test these rules. If the rules do not assign the appropriate users to the team of the template, you can publish the TMR document. By publishing the document, the system will run through a validation to make sure the rules have been created correctly. If there are any issues with the file, errors will be shown when publishing. This prevents you from having to publish a version of your template until you are able to ensure that the rules you have created will work as expected.

When you make an edit to the TMR file in a published template, the updates will not be available in existing projects unless a Template Upgrade is performed.

Defining Team Member Rules Restrictions

Team member rules are supported in the following template types:

  • Contract request
  • Contract workspace
  • Sourcing request
  • Sourcing project
  • Classic supplier performance management
  • Issue management

Log in to track your progress & complete quizzes