Create teams in ITSI

Implement teams in IT Service Intelligence (ITSI) to restrict service-level and episode-level information to only the departments or organizations that need access to it. Teams empower domain experts in different areas within an organization to create and monitor the services and episodes that pertain to their department.

Prerequisites

  • See Overview of teams in ITSI to determine whether you need to implement teams for your organization.
  • Plan out what teams you need to create in ITSI. You can create teams for technology areas or for different departments within your organization. Create a team for every area that needs a separate view of ITSI service-level data or that needs to be administered independently within ITSI.

High-level steps

  1. Create team admin roles to administer each team and assign users to those roles.
  2. Create custom analyst and user roles for each team.
  3. Create teams and assign read/write permissions to the team admin roles you created.
  4. Create services within teams.
  5. (Optional) Sharing episodes with other teams using Notable Event Aggregation Policies (NEAPs).

Step 1: Create roles to administer your teams

After you determine the teams you are going to create in ITSI, create roles to administer the services in each team.

  1. Create a role in the Splunk platform for each ITSI team admin.
  2. Configure the roles to inherit from the itoa_team_admin role in order to obtain the appropriate capabilities.
  3. Assign users to each team admin role you created.

For example, the Splunk administrator creates an itoa_finance_admin role that inherits from the itoa_team_admin role for the administrator of the Finance team. The Splunk admin then assigns the Finance team administrator to the itoa_finance_admin role.

Splunk Cloud Platform administrators need to request Splunk Support to create the custom roles needed for teams.

For information about the itoa_team_admin role's capabilities, see Configure users and roles in ITSI. For information about creating custom roles, see About configuring role-based user access.

Step 2: Create custom roles within each team

Create custom roles for the ITSI analysts and users in each team. For example, create an itoa_finance_analyst role that inherits from the itoa_analyst role for the analysts in the Finance department. Create an itoa_finance_user role that inherits from the itoa_user role for the users in the Finance department. You can then assign permissions to the Finance team without allowing access to analysts and users from other departments.

Note: You must configure the itoa_admin role to inherit from the custom roles you create. Otherwise, the itoa_admin role cannot assign permissions to the custom roles. Alternatively, use the admin role to assign permissions.

Step 3: Create teams

Create teams to group services by department, organization, or type of service and control access to the services.

Prerequisites

  • You must have the itoa_admin role to create a team.
  • Before you create a team, you must create the team admin role that will administer the team so that you can assign permissions to the role when creating the team. See Implement teams in ITSI for information.

Steps

  1. Click Configuration > Teams.
  2. Click Create Team.
  3. Provide a team name and description. Duplicate team names are allowed, but be aware of other team names and use naming conventions to avoid confusion.
  4. Assign read or write access to the listed roles as appropriate. The itoa_admin role has read/write permissions by default. If a role has write permissions for a team, a user with this role can create and modify services in the team. The user can't delete a service in the team unless the role has the delete capability for a service.
  5. Click Create.

Note: If you do not see the custom team admin role listed for which you want to assign permissions, make sure the role has been created and inherits from the itoa_team_admin role. If you are logged in using the itoa_admin role, rather than the admin role, also make sure that the itoa_admin role inherits from the custom team admin role and any other custom roles you have created.

Open a team to see the services that belong to it or to review or change team permissions.

Step 4: Create services within each team

After the administrator creates teams, the team admins that are assigned read/write permissions can create services within their teams. When creating a service, a team admin can assign it to any team for which they have read/write permissions. ITSI administrators can also create services in private teams.

Team admins can access all of the KPI base searches, KPI templates, and entities in the Global team when creating services in their private teams. Team admins can also create dependencies on services in the Global team or within the same team. You cannot create service dependencies between services in different private teams. See Overview of creating services in ITSI for more information.

Add existing services to a team

CAUTION: Adding a service to a team breaks service dependencies if the service is dependent on another service that cannot be accessed from the new team. If a service is dependent on another service within the same team and one of the services is moved to another team, that dependency is broken. A service in a private team cannot have a dependency on a service in another private team. To workaround this, share the services between two teams or put the service in a global team to create dependencies.

If you're implementing teams in a previously configured environment, you might already have existing services you want to assign to a team.

  1. From the ITSI main menu, select Configuration then Service Monitoring then Services.
  2. Click the checkboxes next to the services you want to add to a team.
  3. Click click Bulk Action then Edit Team.
  4. Select the team to add the services to.
  5. Click Save.

Move a service to a different team

CAUTION: Moving a service from one team to another team breaks service dependencies if the service is dependent on another service that cannot be accessed from the new team. If a service is dependent on another service within the same team and one of the services is moved to another team, that dependency is broken. A dependency between services can only be created if the services are shared across teams.

Prerequisite

You must have write permissions for both teams to move a service from one team to another.

Steps

  1. Click Configuration > Teams.
  2. Select the team containing the service you want to move.
  3. Select the name of the service you want to move.
  4. Go to the Settings tab.
  5. Click the Team dropdown and select the team to move the service to.
  6. Click Save.

To move more than one service at a time, click Configuration > Services and select the checkboxes next to the services you want to move. Click Bulk Actions > Edit Team and select the team to move the services to.

Share service to a different team

Note: Sharing a service with another team breaks service dependencies if the service is dependent on another service that cannot be accessed from the new team. Once shared, the shared team gets read-only access to the service. The shared team can view service details, add dependencies, and view the service in the service tree. The shared team cannot edit or delete the service.

You must have itoa_admin or itoa_team_admin role access to share a service.

  1. Click Configuration > Teams.

  2. Select the team containing the service you want to share.

  3. Select the name of the service you want to share.

  4. Click the edit icon to open Edit Permissions.

  5. Note: The preceding Edit Permissions workflow applies to service sharing. It does not configure owner-team or shared-team permissions for NEAPs.

    Click + Add team and specify the team name.

  6. Click Save.

To share more than one service, click Configuration > Teams > Share Services and select the checkboxes next to the services you want to share. This provides read-only access to all the selected services for all users within the team.

Step 5: Sharing episodes with other teams using NEAPs

Episode Granular Permissions is enabled by default from ITSI 5.0. It controls access to episodes generated by notable event aggregation policies (NEAPs) through an owner team and shared teams. After an upgrade to ITSI 5.0, the owner team for all existing NEAPs is set to Global. Review the owner team for each NEAP and update it as needed.

Prerequisites and important considerations

  • Episode Granular Permissions is enabled by default in ITSI 5.0. If it is deactivated, the legacy role-based Actions → Edit Permissions option is shown.
  • NEAP access is controlled through an owner team and shared teams.
  • Shared teams receive read-only access.
  • Team-based permissions restrict episode visibility and support team-scoped episode actions.

  • You can assign non-Global owner teams and shared teams to individual NEAPs as needed.

  • Configuring owner and shared teams does not require a separate data migration or KV Store modification.

Steps

  1. From the ITSI menu, select Configuration > Notable Event Aggregation Policies.

  2. Open the NEAP that you want to configure. To edit a NEAP, a user must be a member of the NEAP owner team, have write permission for that team, and have the write_itsi_notable_aggregation_policy capability.

  3. Open Filtering Criteria and Instructions.

  4. Expand Aggregation Policy and Episode Permission.

  5. Select the owner team. After an upgrade to ITSI 5.0, the owner team for all existing NEAPs is set to Global. This assignment does not by itself give every user permission to edit the NEAP. The NEAP owner team is not the same as the individual owner assigned to an episode in Episode Review.

  6. Select any shared teams. Shared teams have read-only access and cannot edit the NEAP.

  7. Click Save.

Known Limitations

Important: In ITSI 5.0, configure NEAP owner and shared teams by editing the NEAP policy and opening Filtering Criteria and Instructions > Aggregation Policy & Episode Permissions. Do not use the service-sharing Edit Permissions workflow for NEAP permissions.

  • Bulk editing team permissions for multiple NEAPs is not available; configure permissions in each NEAP policy.

  • Reassign associated NEAPs before deleting a team.

  • Bulk sharing of NEAPs is not available.

  • Changing the owner team can reset the episode assignee and action-rule assignees to Unassigned; review these fields after changing the owner team.