1. Implementing Product Management
  2. Object Conditions

Object Conditions

You can create conditions to define restrictions on a specific object based on one or more of its attributes, using logical operators to combine the conditions as needed.

The conditions that you create will be available for selection when you create permission sets and on the Search Conditions page.

Example: A condition to filter manufacturers located in the United States with an Active status.

Note:
  • You can delete a condition that isn’t used in any permission set.
  • You can delete up to 25 conditions in a single operation from the search page. If you select more than 25 conditions, the delete action will be disabled.

Create a Condition

  1. Navigate to the Product Management work area.
  2. In Actions, click Teams.
  3. On the Search Teams page, select Conditions from the Search Teams drop-down list.
  4. Click Create Condition and select the object for which you want to create the condition and enter the object details.
    1. Name: A unique name for the condition.
    2. Description: A short description of the condition.
    3. Active: By default, this is set to Yes.
    4. Attribute: Select the attribute on which you want the rule to be set up. The attribute list consists of the main attributes for the object and the extensible flexfield attributes.
    5. Operator: Select an operator such as equals, is, or not equal to.
    6. Value: Provide the attribute value.

      Repeat the steps to create a condition for another object.

  5. Click Save.

    You can also set up nested rules with a combination of 'AND' and 'OR' to meet your business requirement.

Filter Item Classes and Workflow Types

You can create conditions using the Is (inclusion) and Is Not (exclusion) operators for the Item Class attribute on items and the Workflow Type attribute on workflows. These operators allow you to include or exclude item classes and workflow types based on their position in the hierarchy.

When you use an Is operator for item class or workflow type, access is granted to the selected value and all values underneath it in the hierarchy.

When you use the Is Not operator, access is denied to the selected value and its entire subordinate hierarchy.

For example, let’s say you've an item class hierarchy as follows:
  • Root Item Class
    • Electronics
      • Laptop
      • Desktop
    • Hardware
      • Server
      • Storage Device

For the condition “Item Class Is Not Electronics,” access is denied to Electronics and its subordinate classes, such as Laptop and Desktop, but is granted to other item classes, such as Root Item Class, Hardware, Server, and Storage Device.

Similarly lets say you've a Worflow Types as follows:
  • Engineering
    • Processor Upgrade Change
      • Firmware Revision Change
  • Corrective Action
    • 8D Corrective Action
    • Root Cause Corrective Action
For the condition “Workflow Type Is Not Processor Upgrade Change, access is denied to Processor Upgrade Change or its subordinate workflow types, such as Firmware Revision Change, but is granted to other workflow types, such as Engineering, Corrective Action, 8D Corrective Action, and Root Cause Corrective Action.

For the condition Workflow Type Is Processor Upgrade Change, access is granted to Processor Upgrade Change and all workflow types beneath it in the hierarchy, such as Firmware Revision Change. Access is denied to other workflow types, such as Engineering, Corrective Action, 8D Corrective Action, and Root Cause Corrective Action.

Extensible Flexfield Attributes in Conditions

Here’s what you must know about using extensible flexfield attributes in conditions:

  • If you've added new extensible flexfields, you must deploy these for the security to be defined based on those attributes.
  • If you make any updates to the conditions containing extensible flexfield attributes, you must rebuild the index for the object to apply the updates to the access control list.

Allow Signed-in Users to Access Items and Manufacturers

You can grant View or Manage privileges for all items and manufacturers to signed-in users for the items and manufacturers they created. To provide access, select $User as the value for the Created By attribute when you define the condition for items and manufacturers. By setting a condition such as Created By = $User and associating it to a permission set and team, you grant team members access to all items or manufacturers they've created.

The $User represents the signed-in user.

Allow Signed-in Users to Access Workflows

You can provide view or manage access for all workflows to signed-in users if they’re the creators, assignees, or requesters of the workflow. To provide access, select $User as the value for the Created By, Assigned To, and Requested By attributes when you define the condition for workflows. For example: By setting a condition such as Assigned To = $User and associating it with a permission set and team, you grant team members access to all workflows assigned to them.

The $User represents the signed-in user.

Allow Approvers and Reviewers to Access Workflows

You can configure access to workflows such that approvers and reviewers can view or manage workflows by creating a condition with the value of Approver (or Reviewer) Attribute set to $USER.

When you create a condition with Approver set to $USER and associate it with a permission set and a team, access is granted only when both these conditions are met:
  • The user is in the approvers list (for the workflow), either individually or part of a role.
  • The user is in the team created for the workflow (added as an individual, part of a role, or part of a filtered list).
Note:
  • After you add or remove users from roles (in Security Console), you must run the Refresh Access Control List for Teams scheduled process to synchronize users in the role for conditions that include the $user value.
  • These permission sets apply across workflow objects and statuses, regardless of how approvers and reviewers are added to the workflow object.
  • An Approver or Reviewer has access to all workflow statuses unless you include the Status attribute in the conditions to restrict access to a specific status.
  • When a workflow approval is reassigned, only the new approver is granted the access.
  • When a workflow approval is delegated, both the original approver and the delegate are granted access.