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 TDNext or TDClient. 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, and asset/CI applications. Granting this admin access will only give the user 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 TDNext or TDClient. 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 to match up with process roles, administrative or governance oversight, or any other requirements prompting the breakout of a role. It is a best practice to keep the number of security roles minimized to ease administration. However, if a unique set of permissions are needed, create a new security role.
Ticketing Administration
Those who have been allowed to administrate a ticketing app will be allowed to change configurations including forms, attributes, workflows, and settings. The will not be able to affect Shared Settings, which include impact, urgency, priority and type categories. These settings only global admins can affect as they will impact all ticketing applications.
Be aware that there are some settings and functionality that do not require administration and these things are configured via TDNext 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
Client Portal Administration
Client portal admins can change any settings around the site, attributes, services, articles and categories within the application. These configurations affect the general appearance and structure of the portal.
However, there are non-admin security permissions that can be granted to allow for the decentralization of oversight and administration via security roles. 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 around knowledge roles and processes but may have considerations around service catalog permissions as well.
Asset/CI Administration
The administration privileges around asset/CI apps is mostly centered around 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 TDNext application. The following is done within TDNext, but can be limited via permissions in security roles:
- Product types
- Vendors
- Product models
- Imports - assets/CIs, vendors, product models, product types
- Creation / editing / updating of assets/CIs
- Addition of relationships between assets/CIs
Guidance
TDX generally recommends decentralizing administration where possible. The ease of administration and performing some of the TDNext 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 levels of security roles and administration and set up roles and identify admins as warranted.
When organizations look to branch out TDX usage into other departments, this becomes an empowering capability to have them administer their own respective area 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 might consider allowing them to create new services. This can greatly alleviate the overhead for the department that oversees the TDX service and leads to greater satisfaction of TDX usage as they can easily adapt the tool other departments' needs.