Global portal settings

Introduction to global portal settings in ConSol CM

The Global portal settings page provides an overview of all the settings which are relevant for CM/Track and not part of a specific portal configuration. These settings apply to all portal configurations. They can be configured on the respective pages.

Concepts, terms and definitions

Concept	Other terms	Definition
portal user profile	CM/Track user profile, Track user	User profile for contacts who work with CM/Track. The permissions for the user profile are defined by assigning roles. The user accounts for the contacts are created in the Web Client by selecting a CM/Track user profile and entering the credentials for the contact.
customer group		Group of customers with a specific contact model and permissions
REST		Mechanism used for communication between CM/Track and the ConSol CM server
case history		Log of all changes which are done to a case; for CM/Track, only comments, emails and attachments are relevant
workflow		Business process implemented for cases in a certain queue
credentials	login data	Information of a specific user needed for logging in to an application, e.g. user name and password
authentication		Process to confirm the identity of the users

Available settings

The settings are organized in several tabs.

Authentication

The following settings are available:

• Authentication method: Determines the authentication method for CM/Track if the internal OIDC provider is used. You can configure database or LDAP authentication or a combination of both (the first method is tried first). See Authentication for details about the needed data.

• Provider type: Select “Internal” to use the ConSol CM authentication application as OIDC provider. Select “External” if a third-party application, such as Azure AD or ADFS should be used. Saved to the system property cmas-core-security, oidc.track3.providerType.default. Only relevant for CM/Track V3.

• Global logout: Determines if the user is also logged out from the OIDC provider when logging out of CM/Track. For an internal provider, the value “True” should be selected. For an external provider, the value is usually “false”, so that sessions in other applications, which are provided by the same provider, are not closed. Saved to the system property cmas-core-security, oidc.track3.globalLogout.default. Only relevant for CM/Track V3.

• Redirect URI: Enter the redirect URI where authentication responses can be received. This is either the OIDC endpoint on the ConSol CM server running CM/Track or on the load balancer. Example: http://localhost/cm-track/oidc/. Saved to the system property cmas-core-security, oidc.track.redirectUri.default.

• URL of the authentication authority: Enter the URL of the authenticating authority. Example: https://localhost/cmas-auth-portal-user. Saved to the system property cmas-core-security, oidc.track3.authority.default

• Client ID: Enter the client ID (application ID) of the application, as registered in the OIDC provider. Saved to the system property cmas-core-security, oidc.track3.clientId.default.

• Client secret: Enter the secret of the client, generated by the OIDC provider. Saved to the system property cmas-core-security, oidc.track3.clientSecret.default.

• Name of claim: Enter the name of the claim in the ID token which is used to map the user to a contact in ConSol CM. The value depends on the ADFS settings; the default values are “upn” and “unique_name”. Saved to the system property cmas-core-security, oidc.track3.usernameClaim.default.

• Regex for mapping user names: Define the regular expression used for mapping the user name claim values to ConSol CM user names. Saved to the system property cmas-core-security, oidc.track3.usernameRegexp.default

  • “upn” as claim: (.*)@.* will transform the claim value “user1@sso.yourdomain.com” to “user1” and look up “user1” in the ConSol CM database.

  • “unique_name” as claim: .*\\(.*) will transform the claim value “SSO\user1” to “user1” and look up “user1” in the ConSol CM database.

The Global settings page allows to configure SSO for the default configuration. This configuration is used for CM/Track V2. For CM/Track V3 it is only relevant if more than one OIDC configuration is needed, see Using a portal configuration for several URLs.

Credentials

The following settings are available:

• Portal user profiles: Read-only. Displays the users who can be assigned to contacts to grant them permissions for CM/Track. You need to create at least one portal user profile on the Users page.

• Portal roles: Read-only. Displays the roles which are assigned to portal user profiles and contain permissions to enable contacts to access their cases in specific queues. You need to assign at least one role with the required permissions to your portal user profiles. Create a role on the Roles page.

  Roles with a “C” have the setting Access cases of own company which allows the contacts to access all cases in their company.

• Customer groups: Read-only. Displays the assignment mode of the portal user profiles to the contacts. This is defined for each customer group on the Customer groups page. Possible values:

  • None/Internal: Default. CM/Track is not used or profile is assigned via script.

  • Fixed: The selected profile is assigned automatically.

  • Manual: The profile needs to be assigned in the Web Client.

• Credential fields: Read-only. Displays the contact fields which hold the user name, LDAP ID or password as determined by the settings User name for CM/Track, LDAP ID for CM/Track and Password for CM/Track. The required information depends on the configured authentication method, see Authentication. You need to create the credential fields for your selected authentication method on the Contact fields page.

• Password reset template: Displays the template for the email which is sent when the contact wants to reset his password. You can edit the template content but not its name. The property cmas-core-server, url.track.auth needs to point to the URL where the authentication application is deployed.

• Template for contact notification about blocked account: Template for the email which is sent to the contacts if their account was blocked due to many failed login attempts. The property cmas-core-server, url.track.auth needs to point to the URL where the authentication application is deployed.

• Template for administrator notification about blocked account: Template for the email which is sent to the administrator if a contact's account was blocked due to many failed login attempts. The property cmas-core-server, url.track.auth needs to point to the URL where the authentication application is deployed.

• CM/Track user names case-sensitive: Determines if the user names (logins) of CM/Track users are case-sensitive (true) or not (false). Saved to the system property cmas-core-security, policy.track.username.case.sensitive.

Case fields

The following settings are available:

• Check case field availability: Determines if only fields which have the Availability via REST setting are available in CM/Track (true) or if all fields are available (false). Saved to the system property cmas-restapi-core, security.fields.customer.exposure.check.enabled.

• Fields available via REST: Shows the fields which have the setting Availability via REST for the field or, if not set, the setting of Availability via REST for the field group. You can apply this setting in the Settings tab of the field or field group on the Case fields page. You can switch to the field by clicking the Jump to field to edit icon.

Case history

This section shows the text classes whose comments, emails and attachments from the case history are shown in CM/Track. You need to have at least one text class which allows the customers to see their own content. Usually, this is the default text class for content from CM/Track created during the setup, which has the setting All entries are visible to the customer. In addition, you can apply the setting Only emails (incl. email attachments) with the customer as sender or recipient are visible to the customer to your default text classes for incoming and outgoing emails and attachments. You can review the text class settings on the Text classes page.

Workflow

This section shows the workflow activities which are displayed in CM/Track. They can be executed by users who have Execute activities permission for the respective queue. You need to select Expose to customers for each activity which should be available in the respective workflow on the Workflows page.

General

The following settings are available:

• FAQ queues: Read-only. Displays the queues whose cases are available on the FAQ page for all users in CM/Track. You can select the FAQ checkbox for the desired queues on Queues page.

• URL of the CM/Track instance: Enter the URL which should be used in links to cases in CM/Track, e.g. links inserted in Text templates and using the method linkTo.track(ticket). Saved in the system property cmas-core-server, url.track.

• URL of the authentication authority: Enter the URL which should be used in the password reset template for CM/Track. Saved in the system property cmas-core-server, url.track.auth.

• CSRF filter enabled: Determines if the the CSRF filter is active to protect the system from cross-site request forgery attacks (true) or not (false). Saved to the system property cmas-restapi-core, csrf.request.filter.enabled.

• Allow empty Origin/Referer headers: Determines if requests with empty Origin/Referer headers are blocked (false) or not (true). Saved to the system property cmas-restapi-core, csrf.domain.allow.none.

• Whitelisted domains for the CSRF filter: Enter the list of domains which are allowed in Origin/Referer headers and will not be blocked by the CSRF filter, separated by commas. Saved to the system property cmas-restapi-core, csrf.domain.white.list.

• Access to own customer group only: Determines if contacts can see cases which have additional contacts from another customer group (false) or not (true). Saved to the system property cmas-core-security, contact.inherit.permissions.only.to.own.customer.group.

• Comment author not included in REST response: Determines if the author of a comment is available via REST API (false) or not (true). Saved to the system property cmas-restapi-core, comment.authors.disabled.

• Only allow access to own data: Determines if a contact can only access data of his company and other contacts of the company via REST API (true) or if other contact data is accessible (false). Should be set to true for security reasons. Saved to the system property cmas-restapi-core, security.restrict.unit.access.to.own.data.

Basic tasks

Setting up CM/Track

Perform the following steps to set up CM/Track:

1. Install CM/Track either in the same application server as ConSol CM or in a separate Tomcat, see ConSol CM Setup and Operations Manual.

2. Enable the communication between ConSol CM and CM/Track in the General tab by setting the appropriate values in CSRF filter enabled, Allow empty Origin/Referer headers and Whitelisted domains for the CSRF filter

Granting access to CM/Track

Perform the following steps to grant the customers access to CM/Track:

1. Determine the authentication method, if an internal OIDC provider is used, see Authentication.

2. Configure the permissions for the contacts:

   1. Create a role with the permissions for the desired queues and the customer group which the contacts belong to.

   2. Create a CM/Track user profile which has the new role assigned.

   3. Decide how the CM/Track user profile should be assigned to the contacts.

   4. Configure contact fields with the login information, depending on the selected authentication method.

   See Credentials for further details.

3. Fill out the login data for the individual customers on their contact pages in the Web Client. If the user profile assignment is not fixed, you also need to select the appropriate CM/Track user profile in the Portal user profile field.

Defining data availability

You need to decide which part of the information stored in the customers’ cases you want to share with the customers and which information should be kept internal. There are two aspects which need to be handled for this purpose:

• Case history entries: comments, emails and attachments
• Case fields

Visibility of history entries

The visibility of case history entries is configured using text classes, see Text classes. Only comments, emails and attachments which have a text class with specific settings are visible for the customer when he views a case. Two settings can be used:

• All entries are visible to the customer

• Only emails (incl. email attachments) with the customer as sender or recipient are visible to the customer

Comments and attachments which are added by the customers themselves using CM/Track are visible by default because the default text class for content from CM/Track, which has set All entries are visible to the customer, is automatically applied. In addition, you can select Only emails (incl. email attachments) with the customer as sender or recipient are visible to the customer for your default text classes for incoming emails, outgoing emails and attachments to ensure that the customers are able to see their own emails.

When a Web Client user wants to share additional comments, emails or attachments with the customer, he needs to set a text class which is visible to the customer to the respective history entry.

You can see which text classes are configured for CM/Track in the Case history tab.

Visibility of case fields

The visibility of case fields in CM/Track depends on three aspects:

• Global Check case field availability setting

• Displayed fields setting in the portal configuration

• Availability via REST setting for individual fields or field groups

Check case field availability

Determines whether the case field settings are checked or not. Can be set in the Case fields tab or in the system property cmas-restapi-core, security.fields.customer.exposure.check.enabled.

• true: The customer can only see the case fields which are explicitly set to visible in CM/Track.
• false: The customer can see all case fields in CM/Track.

Displayed fields

Determines whether all available fields or only fields added explicitly to the portal configuration are shown. Can be set in the Case fields section of the portal configuration.

• All fields available via REST: Case fields which are not added explicitly but which are set to be available will be displayed.
• Only fields added explicitly: Only case fields which are added explicitly are displayed.

Availability via REST

If case field settings are checked (see Check case field availability), all case fields which should be shown in CM/Track need the Availability via REST setting either for the group or the field. The value of the field setting overwrites the value of the group setting.

• Case field groups: Setting Availability via REST with the following values:
  • Full access: The fields in this case field group are displayed in CM/Track and their values can be modified.
  • Read-only access: The fields in this case field group are displayed in CM/Track.
• Case fields: Setting Availability via REST with the following values:
  • Full access: The case field is displayed in CM/Track and its value can be modified.
  • Read-only access: The case field is displayed in CM/Track.
  • No access: The case field is not displayed in CM/Track.

The settings Visible (for case field groups) and Visibility (for single case fields) will work in any case and are stronger than the Availability via REST settings, i.e. when a group or field is set to invisible, it will not be displayed, no matter the availability via REST.

Combinations

The following table shows the effect of the different combinations on a certain field.

Check case field availability	Displayed fields	Availability via REST	Effect
false	Only fields added explicitly	*	The case field is only displayed if it is added to the portal configuration.
false	All fields available via REST	*	The case field is displayed.
true	*	no	The case field is not displayed.
true	Only fields added explicitly	yes	The case field is only displayed if it is added to the portal configuration.
true	All fields available via REST	yes	The case field is displayed.

Advanced tasks

Using FAQs

You can use the FAQ functionality of CM/Track to create FAQ entries, which cover common problems and questions, so that the customers can look for a solution by themselves before creating a new request. Each FAQ entry is a case in a dedicated FAQ queue. The CM/Track users can access the FAQs by clicking FAQ in the main menu. The FAQ page includes a list of entries and a search field. If there are several FAQ queues, the users can filter the entries by queue.

You need to perform the following steps to implement the FAQ feature:

1. Create an FAQ workflow on the Workflows page.

2. Create a queue for the FAQ workflow on the Queues page. The checkbox FAQ must be selected for the queue. As FAQs do not need any customer, you can select None for the Customer assignment. In addition at least one text class which has the checkbox All entries are visible for customers selected must be assigned. This text class must be applied to all the comments which should be visible to the customers in CM/Track.

3. Create a role with view permissions to the FAQ queue on the Roles page. If a customer group is assigned to the queue, the role must also have view permissions for this customer group, even though the customer is not displayed in CM/Track.

4. Assign this role to the CM/Track user profile on the Users page.