Create and edit business rules

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 rule validation helps to improve data quality and operational efficiency by preventing actions that could compromise data integrity.

Organizations that have the Workflow Ultimate package can also configure business rules to automate actions for the created, edited, or modified object when certain conditions are met. Available actions include sharing the object or attaching a custom form to the object.

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

Scenarios for business rules

Scenarios for business rule validation

The format of a business rule validation 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. Use $$ISAPI to trigger the rule only in the API. Use !$$ISAPI to enforce the rule only in the user interface and allow users to bypass the rule through 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.

Some simple business rule scenarios are:

The system permits one business rule per object per trigger. For example, one edit trigger rule is allowed for issues. However, you can include multiple rules in a formula with nested IF statements.

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")
)

Enable localization in a Business Rule

If your organization uses custom localization, you must enable translation of a business rule message in the business rule. If translation is not enabled, the message appears to the reader in English, even if the message text is in the Localization list and the user’s browser is set to the appropriate language.

When configuring the rule, insert the word TRANSLATE before the message, and enclose the message in parentheses.

Example:

This example assumes that the message “You cannot edit completed projects” is included in the localization area of Setup, and that the user’s browser is set to the localized language.

For information on custom localization, see Configure custom localization.

Scenarios for business rule automation

The format of a business rule automation is “IF the defined condition is met, then the selected automation is triggered.”

Business rule automation formulas do not require an error message

To ensure that an automation runs whenever the selected object and action occurs, such as when a project is created, use the following formula:

IF(true, true)

To share a project only if that’s project has been approved, use a formula like the following:

IF({status} = "APR", true)

You can use wildcards in business rule actions, as described in the section Scenarios for business rule validation.

Add a new business rule

Business rule automation options

You can set these actions to automate when the business rule is triggered. Available actions depend on the selected object type.

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: