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.

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:
  • 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.