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 Organization data .
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

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 Organization data.

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:

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.

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.