Data access model

An administrator enables users to access BMC Helix Business Workflows and its data by using the following security measures:

  • Permissions—Authorizes users by assigning them different roles and permissions. 
  • Data access model—Defines which users can access the data.

Case Management data access model

In BMC Helix Business Workflows, different types of access are associated with different types of case data. The data access model determines which user can access which type of data. 

A case can also contain child records that only specific users can access.

Case data has the following categories:

  • Configuration data—Users can use configuration data to create records. All the users of a company can access this data.
  • Transactional data—Users create transactional data (record) by using the configuration data. Only the members of the support group associated to the record have access to this data.

Case data has the following types of access:

  • Company-wide access—With this access, all the users of a company have access to its data. If the company has a child company, users cannot view the child company's data. For users to access the child company's data, an administrator must add the company to the supported organizations for the users.
    For more information about organization data, see Creating and modifying companies and organization structures.

    By default, the case company and owner company of a case template and task template has read access to the templates.

  • Support Group-wide access—With this access, only the members of the support group associated to a record have access to the data.

The following table lists the examples of data types and the type of accesses associated with them:

Type of data

Example

Type of access

Configuration data

  • Case template
  • Case assignment mapping
  • Case approval mapping
  • Task template

Company

Transactional data

  • Case
  • Requester's responses
  • Task

Support Group

Example

Data access model example.png

Consider an example where, a case manager creates a case template for a leave application. By using this template, as a case agent, you create a case for an employee who wants to apply for maternity leave. All the support groups in your company have access to the template. The HR support group has access to the case only if the case is assigned to it. 

In this example, the case template is a configuration data that is used to create a case, and the case is a transactional data (a record) created by using the template.

Support Group-wide access

The following table determines which users or groups have access to the case:

Agent/Support group

Type of access

Assignee

Write

Submitter

Write

Assigned support group

Write

Support group configured for read access

For more information, see Configuring-default-access-for-cases.

Read

The following table determines which agent or support group has access to a case template or task template:

Support group/Agent

Type of access

Owner support group of case and task template

Write

Case business analyst and case manager (Have write access only if they belong to the owner support group, case company, or owner company of the template.)

Write

Template submitter (creator) and owner

Write

For more information about support groups, see Creating and modifying companies and organization structures. 

Access associated with child records of a case

In BMC Helix Business Workflows, cases can contain the following child records:

  • Requester's Responses—These records contain questions and responses shared by individuals associated with a case. This communication is populated from service requests created in applications like BMC Helix Digital Workplace Advanced.
  • Tasks—These records are created for cases to enable the agent to focus on one action at a time and execute it successfully. Tasks are created either by using task templates or by adding task details in ad hoc tasks.

The following table lists who can access the child records of a case:

Child record

Accessible by

Task

  • Support group of the parent case.
  • Support group to which the task is assigned.

Requester's Responses

Support Group of the parent case.

The following video (2:47) explains why the user access to case data is restricted:

Video icons.png https://youtu.be/pLxyfcITf8k

Knowledge Management data access model

The BMC Knowledge Management shared application uses row-level security (RLS) to control access to fields. In the BMC Knowledge Management shared application, the administrator can use RLS to control access to knowledge articles, knowledge sets, review cycle, and so on. RLS is applied by using Security Labels in BMC Helix Innovation Studio. 

The following table describes the Security Labels required for BMC Knowledge Management shared application:

Security Label name
(Field modification permission) 

Description

Best practices for granting permissions

Assignee
(Owner of the knowledge article)

Grants write access to knowledge articles only. The permission is usually assigned to users who can take ownership of articles and can change the assignments.

Grant this permission to advanced knowledge users who have knowledge contributor or above role.

Assignee Group
(Group of owners of knowledge article) 

Grants write access to knowledge articles only. The permission is usually assigned to a group of users who can take ownership of articles, and can change the assignments.

Grant this permission to a group of advanced knowledge users who have knowledge contributor or above role.

Submitter

Grants write access to new knowledge articles only. This permission is usually assigned to junior knowledge users and trainees and enables them to create and promote articles to Draft status only.

Grant this permission to standard technical users who require access to create knowledge articles from incidents or other requests.

Read Only

Grants view access to knowledge articles in any status without write privileges. This permission is usually assigned to support staff who only search and view articles.

Grant this permission to all users who need to view knowledge articles.


Invalid macro parameters used for the [show-if] macro. Cause: [Unable to convert value [SELF]. Allowed values are (case insensitive) "NONE", "AUTHENTICATED" or "ANONYMOUS".]. Click on this message for details.


Invalid macro parameters used for the [show-if] macro. Cause: [Unable to convert value [SELF]. Allowed values are (case insensitive) "NONE", "AUTHENTICATED" or "ANONYMOUS".]. Click on this message for details.

Invalid macro parameters used for the [show-if] macro. Cause: [Unable to convert value [SELF]. Allowed values are (case insensitive) "NONE", "AUTHENTICATED" or "ANONYMOUS".]. Click on this message for details.

Service Level Management data access model

In BMC Helix Business Workflows, the security labels of the Case record definition are replicated for SLM, ensuring that the users who have access to request data can also view the associated measurements.

The following table describes the Security Labels required for SLM:

Security label name

Description

SLM read permission

Grants read-only access to fields and record definitions.

SLM write permissions

Grants read and write access to fields and record definitions.

Related topics

Setting-up-roles-and-permissions

Assigning-functional-roles-and-permissions

Associating-cases-knowledge-articles-and-related-users-to-cases

Creating-case-templates-and-task-templates

Creating or modifying security labels in record definitions to define hierarchy


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*