This overview article will help TDX administrators determine the approach for application administration and security role identification. The user must be a TDX administrator to configure any related settings.
Overview
Developing the approach for determining system administration becomes more complex as organizations branch out TDX usage into other departments. Some TDX applications also allow for some settings and content to be structured within the applications via Work Management or the Client Portal. The following provides a bit of guidance to better understand the boundaries of administration versus what security roles may be used for.
Global Administration
It is a good practice to keep TDX system-level administration down to a minimum as these admins can affect any area of the system. Since PPM configurations live within the TDAdmin system level, some organizations provide admin access to those who may be knowledgeable and entrusted with management of those configurations. However, it is important to understand that they will have full system admin access. Therefore, each organization should weigh the risk tolerance and trust levels appropriately. Configuration changes should follow appropriate governance and change enablement processes.
Application Administration
TDX allows for administration access to be provided to specific applications as well. This applies to Client Portal, Ticketing, Project, and Asset/CI applications. Granting this admin access will only give the user the ability to affect configurations for that application. This can be a helpful means to decentralize administration and relieve some of the support burden without introducing much risk. In all cases, configuration changes should follow appropriate governance and change enablement processes.
There are a few additional considerations specific to application administration.
Administration vs. Security Roles
It is important to understand that providing admin access to an application does not automatically grant them any extra permissions within Work Management or a Client Portal. The capabilities given to users in these interfaces are controlled by security roles. Security roles have their own set of permissions, which may be granted or not. Security roles may be set up to provide users with various capabilities that align with process roles, administrative or governance oversight, or any other requirements that prompt a role breakout. It is best practice to minimize the number of security roles to ease administration. However, if a unique set of permissions is needed, create a new security role.
Ticketing Administration
Those granted administrative access to a Ticketing app can change configurations, including forms, attributes, workflows, and settings. They will not be able to affect Shared Settings, which include impact, urgency, priority, and type categories. These settings can only be set by global admins, as they affect all Ticketing applications.
Be aware that some settings and functionality do not require administration, and these are configured via Work Management within the application. Some of these are available to all users, while others are controlled by permissions on security roles.
- Surveys
- Ticket imports
- Blackout windows
- Ticket templates
- Scheduled tickets
Project Application Administration
Those granted administrative access to a Project app can change configurations, including custom attributes, project and request sections, searches and reports, statuses, workflows, project request forms, and project request automation rules. They will not be able to affect Shared Settings, which include type categories and priorities. These settings can only be configured by global admins, as they affect all Project and Ticketing applications.
Note that some areas relevant to project management are not part of the Project app and cannot be configured at the application level. Resource Management, Programs and Portfolios, Workspaces, and Time and Expense functionality are managed at the organizational level.
Access to Portfolio Planning and Project Templates is controlled by security role permissions within the Project app: the View Project Request/Portfolio Planning pages permission and the View Project Templates permission, respectively.
Client Portal Administration
Client portal admins can change site settings, styles, attributes, services, articles, and categories within the application. These configurations affect the portal's overall appearance and structure.
However, non-admin security permissions can be granted via security roles to decentralize oversight and administration. This allows users to affect the following directly in the Client Portal app:
- Service categories
- Service / Service offering creation/editing
- Knowledge Base article categories
- Article creation/editing
- Article approvals/publishing
Most security roles center on knowledge roles and processes, but may also include considerations for service catalog permissions.
Asset/CI Administration
The administration privileges for Asset/CI apps primarily focus on key structural elements, such as attributes, forms, and relationship types between items.
Much of the content-related Assets/CI is set up and controlled by users in the Work Management application. The following is done within Work Management, but can be limited via permissions in security roles:
- Product types
- Vendors
- Product models
- Imports - assets/CIs, vendors, product models, product types
- Creation, editing, and updating of assets/CIs
- Addition of relationships between assets/CIs
Guidance
TDX generally recommends decentralizing administration where possible. The ease of administering and performing some Work Management-level changes is simple enough that non-technical resources can take these activities on without introducing much risk. Become familiar with what can and cannot be done by various security roles and levels of administration, and set up roles and identify admins as warranted.
When organizations look to expand TDX usage across other departments, this becomes an empowering capability, enabling them to administer their own areas and usage. For the Client Portal, it may not be necessary to make them an admin of the entire site unless they were taking on their own separate Client Portal. Otherwise, you could just enable them to edit the services they manage and/or create new services. This can greatly alleviate the overhead for the department that oversees the TDX service and leads to greater satisfaction with TDX usage, as they can easily adapt the tool to other departments' needs.