5.1 About PlateSpin User Management

For PlateSpin Transformation Manager, a user is any individual who can access Transformation Manager to plan, monitor, or execute transformation projects. Transformation Manager creates a user account during the installation process, and assigns the user to the System Administrator role. This default user is initially responsible for creating user accounts and assigning roles to them, as well as creating organizations and groups.

Transformation Manager stores user account information and authenticates the user to allow access. Access controls govern the information users can see and the actions they can perform.

5.1.1 System Users and Organization Users

As the default System Administrator user, you must add user accounts and assign them to project roles to enable other users to manage or view project information. When you create a user or group, you can set the user’s scope at one of two levels:

  • System: System users and groups have only the privileges associated with their assigned roles. You can assign system users to the following:

    • System Administrator role (members of the Administrators group)

    • Project Manager

    • Project Architect

    • Migration Specialist

    • Dashboard Viewer role

    • System groups

    You can also assign system groups to the roles, and then manage group membership to make management easier.

  • Organization: Organization users and groups have only the privileges associated with their assigned roles. You can assign organization users to the following:

    • Dashboard Viewer role

5.1.2 Roles

You can assign users or groups to roles that let them plan, monitor, and execute transformation projects. Transformation Manager provides five roles: System Administrator, Project Manager, Project Architect, Migration Specialist, and Dashboard Viewer. Each role carries its own set of responsibilities in the PTM environment. For detailed information about the permissions for each role, see Section B.0, Roles and Permissions.

Roles can be assigned directly or inherited. Inherited roles can be set for system users or groups at the System, Organization, Project, Wave, or Batch level. Inherited roles can be set for organization users or groups at the Organization, Project, Wave, or Batch level. The inherited roles apply across all components in that level for existing and new components, as illustrated in Figure 5-1. For example, if you assign the system user account for John as the Project Manager for an organization, the organization’s existing and new projects automatically inherit the setting.

Figure 5-1 Scope of Permissions for Inherited Roles

System Administrator Role

The System Administrator role has full privileges in Transformation Manager. The initial user account that you create during the installation automatically has this role. You can add system users or system groups to the Administrators group to assign this role. The System Administrator typically performs the following tasks:

  • Configures, maintains, and monitors the health of the PlateSpin Transformation Manager Server.

  • Has all privileges throughout the product.

  • Has exclusive privileges to perform the following tasks:

    • Create and delete organizations.

    • Create and delete projects.

    • Create and delete Operating System types.

    • Assign users and groups to roles at the Organization level.

    • Assign users and groups to the Project Manager role.

  • Can perform all tasks for every role in any project.

Project Manager Role

The Project Manager role can be a user or group. For an assigned project, this role has the permissions necessary to perform the following tasks:

  • Manages the project.

  • Creates and deletes users.

  • Creates and deletes non-administrator groups, and assigns members to them.

  • Assigns users or groups to the Project Architect, Migration Specialist, and Dashboard Viewer roles.

  • Tracks project progress and core statistics, using the dashboard.

  • Performs any of the Project Architect tasks.

    • Creates and deletes waves, batches, and applications.

    • Bulk imports project workloads.

    • Creates and deletes resources.

    • Defines proposed workloads.

    • Submits workloads that are ready for transformation, or withdraws them if transformation changes are needed.

Project Architect Role

The Project Architect role can be user or group. For an assigned project, this role has the permissions necessary to perform the following tasks:

  • Views all information for the project.

  • Creates and deletes waves, batches, and applications.

  • Assigns users or groups to the Migration Specialist role for waves and batches.

  • Bulk imports project workloads.

  • Creates and deletes resources.

  • Defines proposed workloads.

  • Submits workloads that are ready for transformation, or withdraws them if transformation changes are needed.

  • Tracks project progress and core statistics, using the dashboard.

  • Can execute the individual migrations, according to the project plan.

Migration Specialist Role

The Migration Specialist role can be a user or group. For an assigned project, wave or batch, this role has the permissions necessary to perform the following tasks:

  • Views information for the project’s waves, batches, and workloads.

  • Views information for the project’s resources.

  • Executes the individual migrations, according to the project plan.

  • Tracks project progress and core statistics, using the dashboard.

Dashboard Viewer Role

The Dashboard Viewer role can be a user or group. The Dashboard Viewer role has the permissions necessary to view the dashboard information only for an assigned organization, project, wave, or batch. Inherited permissions apply to this role in the child containers if you assign this role at the system, organization, project, wave, or batch level.

5.1.3 Example: Digital Airlines Users

Each project typically has one manager. In this example, the Digital Airlines organization has multiple projects. They want three users to share the project manager role across all of their projects. You want to manage their role assignments in a group instead of individually. The group will receive access rights at the Organization level so that its members can manage any of the organization’s projects.

As a System Administrator user (a member of the Administrators group), you perform the following tasks, as shown in Figure 5-2.:

  1. Create an organization account for Digital Airlines.

  2. Create system user accounts for workers Alice, Ben, and Jacob.

  3. Create a system group DigAir PM.

  4. Assign the three system users to this group.

  5. Assign the DigAir PM group to the role of Project Manager for the Digital Airlines organization at the Organization level.

  6. Create projects for Digital Airlines.

  7. Each project for the organization automatically inherits the group in the Project Manager role.

    With this configuration, any member of the DigAir PM group can manage any project for the Digital Airlines organization.

Figure 5-2 Assigning a Group to the Project Manager Role

You can assign user permissions directly, or indirectly through group membership. If you assign a user to multiple roles, the user’s permissions in the Web Interface are cumulative.

For example, Alice is a system user who is currently assigned to the DigAir PM group. You also want her to perform the System Administrator role for the Web Interface. You can add Alice as a member of the Administrators group to grant her the associated permissions for the System Administrator role. See the Administrators group membership in Figure 5-2.

The Project Manager role provides a user the ability to create, modify, and delete users and groups, without granting the additional authority for tasks associated with the System Administrator role. For example, you can assign Alice the Project Manager role. After Alice creates users and groups, the project managers for the Digital Airlines projects (that is, member in the DigAir PM group) can assign subordinate project roles to them.