Create and edit business rules
The highlighted information on this page refers to functionality not yet generally available. It is available only in the Preview environment for all customers. After the monthly releases to Production, the same features are also available in the Production environment for customers who enabled fast releases.
For information about fast releases, see Enable or disable fast releases for your organization.
A business rule allows you to apply validation to Workfront objects and prevent users from creating, editing, or deleting an object when certain conditions are met. Business rules help to improve data quality and operational efficiency by preventing actions that could compromise data integrity.
A single business rule can be assigned to only one object. For example, if you create a business rule for not editing projects under certain conditions, you can’t apply the same rule to tasks. You would have to create a separate business rule with the same conditions for tasks.
Access levels and object sharing have a higher priority than business rules when a user interacts with an object. For example, if a user has an access level or permission that does not allow editing a project, then those would take precedence over a business rule that permits editing a project under certain conditions.
When more than one business rule applies to an object, then the rules are all followed but are not applied in a certain order. For example, you have two business rules. One restricts creating expenses in the month of February. The second prevents editing a project when the project status is Complete. If a user tries to add an expense to a completed project in June, the expense cannot be added because it has triggered the second rule.
Business rules apply to creating, editing, and deleting objects through the API as well as in the Workfront interface.
Access requirements
You must have the following to perform the steps in this article:
| table 0-row-2 1-row-2 2-row-2 layout-auto html-authored no-header | |
|---|---|
| Adobe Workfront plan | Ultimate |
| Adobe Workfront license | Standard |
| Access level configurations | System administrator |
For more detail about the information in this table, see Access requirements in Workfront documentation.
Scenarios for business rules
The format of a business rule is “IF the defined condition is met, then the user is prevented from the action on the object, and the message is displayed.”
The syntax for the properties and other functions in a business rule is the same as the syntax for a calculated field in a custom form. For more information about the syntax, see Add calculated fields with the form designer.
For information about IF statements, see “IF” statements overview and Condition operators in calculated custom fields.
For information about user-based wildcards, see Use user-based wildcards to generalize reports.
For information about date-based wildcards, see Use date-based wildcards to generalize reports.
An API wildcard is also available in business rules. You can use $$ISAPI to trigger the rule only in the UI or only in the API.
The $$BEFORE_STATE and $$AFTER_STATE wildcards are used in expressions to access the object’s field values before and after any edits.
- These wildcards are both available for the edit trigger. The default state for the edit trigger (if no state is included in the expression) is the
$$AFTER_STATE. - The object creation trigger only allows the
$$AFTER_STATE, because the before state does not exist. - The object deletion trigger only allows the
$$BEFORE_STATE, because the after state does not exist.
Some simple business rule scenarios are:
- Users cannot add new expenses during the last week of February. This formula could be stated as:
IF(MONTH($$TODAY) = 2 && DAYOFMONTH($$TODAY) >= 22, "You cannot add new expenses during the last week of February.") - Users cannot edit the project name of a project in Complete status. This formula could be stated as:
IF({status} = "CPL" && {name} != $$BEFORE_STATE.{name}, "You cannot edit the project name.")
A scenario with nested IF statements is:
Users cannot edit completed projects and cannot edit projects with a Planned Completion Date in March. This formula could be stated as:
IF(
$$AFTER_STATE.{status}="CPL",
"You cannot edit a completed project",
IF(
MONTH({plannedCompletionDate})=3,
"You cannot edit a project with a planned completion date in March")
)
Add a new business rule
-
Click the Main Menu icon
-
Click Business Rules in the left panel.
-
Click New business rule.
-
Select the object type to assign the business rule to, then click Continue.
-
Type the Name for the business rule.
-
In the Is Active field, select whether the rule should be active when you save it.
If you select No, the rule is saved as inactive, and you can activate it later.
-
Select a Trigger for the business rule. The options are:
- On object creation: The rule is applied when a user attempts to create an object.
- On object edit: The rule is applied when a user attempts to edit an object.
- On object delete: The rule is applied when a user attempts to delete an object.
-
(Optional) Enter a Description of the business rule and what happens when it is applied.
-
Build the formula in the formula editor, in the center of the business rule dialog.
The format of a business rule is “IF the defined condition is met, then the user is prevented from the action on the object, and the message is displayed.”
In the formula area, the parts of the business rule you build are the condition, and the message that displays in Workfront when the condition is met.
-
The “object” is the object type you selected when creating the business rule. It is displayed in the heading of the dialog.
-
The “action” is the trigger you selected for the rule: create, edit, or delete the object.
-
Because the object and the action are already defined, you do not include them in the formula.
-
The custom error message is displayed to the user when they trigger the business rule. It should provide clear instructions on what went wrong and how to correct the issue.
You can include a static URL in the error message, to link to documentation or other helpful pages to guide the user on how to modify their action within the constraint of the rule.
In this example, “Learn more” will link to the URL.
"You are not allowed to add a new project in November.[Learn more](http://url)"The URL must be in parentheses, but link text in brackets is not required. You can display the full URL and it will be a clickable link.
This example is a business rule for projects. If the current month is November, then users are not permitted to create new projects, and the message explains this.
For more examples of business rules, see Scenarios for business rules in this article.
-
-
(Optional) Use the formula Expressions and Fields in the right panel to assist with building the rule.
Search for an expression or field to narrow the list of available items.
The list of available fields is limited to fields related to the object type for the business rule.
-
Click Save when you are finished building the business rule.
Activate a business rule
When a business rule is inactive, the Is Active field in the list of business rules displays False. You cannot update the status of the rule in the list view.
To activate a business rule:
- Select the business rule in the list of rules and click the Edit icon.
- Select Yes for Is Active in the business rule dialog.
- Click Save.