The security model in the Pega Sales Automation™ application has been updated to use Pega platform’s Attribute-based Access Control (ABAC) to enforce operator security, compared to Pega 7.3.1, which uses the standard, Role-based Access Control (RBAC).

The ABAC security model in Sales Automation 7.4 allows you to:

• Use the row-level and column-level security features
• Consistently enforce the security rules regardless of how the data is being accessed (Elasticsearch, report definitions or activities)
• Centrally maintain the security rules without any development work on different rules

For more information, see Attribute-based access control.

Before you begin the upgrade process, review the following information:

• By default, the EnableAttributeBasedSecurity Dynamic System Setting is set to true. For more information, see Upgrading your application to use ABAC security.
• All database-related rules add ABAC policy conditions in the generated queries (for example, Obj-Browse, report definitions, Connect-SQL).
• Class join conditions on report definitions must use left joins instead of inner joins to avoid unexpected filtering of rows. For example, to show an accounts list with the corresponding organization's name, if the operator did not have permissions on the organization instance, the inner join filters that row, which is not an expected behavior.
• If implementation teams want to enforce new conditions, then the Access Policies and Access Policy Conditions can be overridden in implementation layers. For more information, see Upgrading your application to use ABAC security.
• Standard associations are shipped for the core objects. While creating report definitions from the report browser, you can use these associations to retrieve information about the associated classes.

ABAC upgrade sample rules

To better understand the security changes in the Sales Automation product layer, perform the following steps:

1. In the Dev Studio search for the following rules:
   • Activities, for example, crmBuildOperatorAccess
   • Sample Access Control Read Policy, for example, crmReadAccess in the PegaCRM-Entity-Contact class
   • Sample Access Control Policy Condition, for example, ReadAccess in the PegaCRM-Work-SFA-Lead class
   • Sample Access Control Update Policy, for example, crmUpdateAccess in the PegaCRM-Work-SFA-Lead class
   • Sample Access Control Policy Conditions for Update, for example, crmUpdateAccess in the PegaCRM-Entity-Org class
   • Global search rules, for example, pySearchWrapper andpyWorkSearch (per case type)
2. Open and review each rule.

Upgrading your application to use ABAC security

Due to ABAC updates, you have to remove the joins and where conditions related to access permissions from the report definitions that are overridden in the implementation layer after the application upgrade.

To upgrade your application to use ABAC security, perform the following steps:

1. In Dev Studio, click Records > Report Definition.
2. Open the report definition that is in the implementation layer.
3. Click Data Access.
4. Remove the Access class join and the corresponding filter criteria.
5. Click Save.
6. Optional: Perform steps 2-5 for every report definition in your implementation layer.
7. Optional: Search for the global search rules.
   1. Remove the filter criteria that looks for presence of TerritoryID in the list of IDs that the operator has access to.
   2. Click Save.
   3. Perform step 7 for global search rules for every case type in your implementation layer.
8. Optional: Click Configure > Org & Security > Tools > Security > Role Names.
   1. Review the Rule-Access-Role-Object (ARO) that is shipped with the product.
   2. Adjust the AROs for all of the access roles that are in the implementation layer and click Save.

If you do not want to use ABAC, perform the following steps:

1. Search for and open the EnableAttributeBasedSecurity DSS.
2. Set the DSS to false.
3. Because the product layer has already been upgraded to use ABAC security, save any report definitions or Elasticsearch-related rules from the product layer into your implementation layer and continue to use joins and filters for access permissions.