Client License Interactions on TDClient


The Projects/Workspaces, Services, Knowledge Base, and Questions applications are available for client interaction. Further, as documented above, each of these applications has a setting to determine whether or not its content is visible to unauthenticated users. Although these application-level visibility settings are respected, there are additional restrictions that can be applied. Each application will be detailed more explicitly in the following sections.


This application allows users to check on project and workspace status from the Client Portal. Although most project management functionality exists in TDNext, this provides a way to monitor project health and perform actions for project members without TDNext access. However, only certain projects will appear in the Client Portal (assuming the application is marked as public).

This is determined by the Client Portal Visibility setting, which can only be changed by users who have permission to manage the project. The setting is configured on a per-project basis, and supports the following values:

  • Public: The project is visible to all users, even those who are not logged in
  • Published: The project is visible to all logged in users, regardless of project membership
  • Membership: The project is only visible to users who are logged in and are listed as a stakeholder on the project

It is worth noting that this setting does not exist for Workspaces. As such, each workspace to which the user belongs will always be displayed in the Client Portal.


This application allows clients to submit service requests to technicians. Services can be configured so that when requested, a work item with the corresponding information will be created in the TDX system to be processed by a technician. The type can be configured in the Request Application / Type field that appears in the Settings tab of the service edit page in the Client Portal. These can be created for projects, tickets, and links, although all three work differently. Each type is detailed more explicitly in the following sections.


This is the simplest type of service, as no work item is created. Rather, when a user clicks the button to submit a link service, a new browser window opens that takes the user to the URL configured for the link. It should be used when the issue can be resolved at the provided web address, and so a TDX work item does not need to be created.

Project Requests

This type of service causes a project request to be submitted, which is later approved or rejected. The approver of the project depends upon the Type that is associated with the request. Each project type has an Evaluator who is responsible for reviewing and taking action on all project requests which are submitted with that type.

The evaluator for a specific project type can only be configured by an administrator. This can be performed in the Admin tool by locating Portfolio Planning > Types, clicking on the name of the type, and changing the value of the Evaluator field. It is a required field, and so all project types have an evaluator for those types of project requests.

It is also worth noting that the information submitted with a service request can be configured. The form to be used on the service can be changed in the Form tab when editing a service. Administrators are able to create/edit the forms themselves in the Admin tool by locating Portfolio Planning > Request Forms and editing the field list as needed.

Any changes to a form will not update existing instances of the form. The new fields associated with the form will only be used the next time that the form is applied to a service.

Ticket Requests

This is the most complex form of service, as it supports all ticketing platforms configured for an organization. The specified platform determines the application in which the ticket is created after the service request is submitted. It is worth noting the primary reviewer of the ticket depends upon the Type specified for the service.

As with project requests, the form to be used on the service can be configured in the Form tab when editing a service. However, the forms that are available depend on which ticketing application has been selected for the service. Administrators (organizational or application) are able to create/edit the forms themselves in the Admin tool by locating Ticketing Applications > [Application Name] > Request Forms and editing the field list as needed.

Any changes to a form will not update existing instances of the form. The new fields associated with the form will only be used the next time that the form is applied to a service.

Knowledge Base

The Knowledge Base application allows users to create articles that convey information to clients. It allows people to create documents for troubleshooting common issues or documenting standard process/procedure, although users can create content as needed. However, it is worth noting that one of the difficulties with knowledge base articles is ensuring that their information is up-to-date as processes change.

To combat this, the TDX system allows clients to leave feedback on Knowledge Base articles. This enables clients to provide suggestions on how articles can be improved, or comment upon which parts of the document are successful. However, it is up to the article's owner to ensure that feedback is addressed. In the Settings tab when editing an article, the Notify Owner on Feedback can be selected so that the user receives an email whenever the article receives feedback.

In addition to allowing for this interaction, there is also a robust permissions system so that sensitive articles can only be seen by intended users. This can be configured in the Permissions tab when editing a KB article or category. The first Inherit Permissions checkbox allows articles to use the same permission settings as the KB category. Otherwise, the article/category will have its own permission enforcement instead of inheriting from the parent.

When marked as Public, an article/category will be visible to all Client Portal visitors, including unauthenticated users. Otherwise, being marked as Published will only display the article/category if the user is logged in. This can be used in combination with the Article Permissions setting if the article should have group-based visibility. Any number of user groups can be selected, and either the Allow ONLY or Allow all EXCEPT options can be selected for how the permission will affect the list of groups.


Although knowledge base articles help to convey information, this does not make it easy to have conversations with clients. The Questions system can be utilized in this way to encourage communication between the technician and the client. As with the Knowledge Base application, questions support permission enforcement.

However, these permissions are enforced in a different manner than for KB articles. First, there are only category-level permissions and they cannot be configured at the question level. In addition, there is no concept of group permissions in the Questions system.

Rather, there are Public, Published, and Not Published options. As in the Knowledge Base, Public articles are visible to all users and Published articles require the user to be logged in. However, marking a question category as Not Published will ensure it is only visible to authenticated users who have access to TDNext.

A list of all categories can be seen in Admin by locating Client Portal > Question Categories. However, this page only supports deletion of categories. Any category creation/editing must be performed in the Client Portal. Clicking the name of a category in Admin will open up the category in Client, where it can be edited.


Article ID: 16848
Wed 9/28/16 9:23 AM
Mon 6/29/20 11:19 AM

Related Articles (1)