Using Business Rules in STEP

Wherever business rules are used, they are always tested or executed in relation to one object at a time, and in a specific context / workspace. The most common places to use business rules are included in the list below.

  • Approvals - Conditions can be tested when approval is attempted on an object under revision control, and the condition can allow or prevent the approval. Actions executed on approval and can modify data in STEP (typically data on the object being approved), send emails etc. related to the approval.

For more information, refer to Business Rules on Approval documentation here.

  • Automatic Classifications - Actions can be executed to automatically classify objects, and can be applied, for example, on approval, during an import, or as a part of a workflow.

For more information, refer to Using Automatic Classification with Business Actions documentation here.

  • Bulk Updates - Conditions can be tested as a precondition for executing an action. Actions can be executed.

For more information, refer to Run Business Rule Operation documentation here.

  • Conditional Attributes - The JavaScript business action 'Conditionally Invalid Values' bind resolves to a set of all values.

For more information, refer to Business Rules with Conditional Attributes documentation here.

  • Data Profiles - Conditions can be tested against all objects in a category (for example, a part of the Product hierarchy), and the result of the tests can be displayed on the Profile Dashboard.

For more information, refer to Business Conditions in Data Profiling documentation here.

  • Event Processors - Actions can determine when and how to act upon the events from the event processor. This is useful when changes occur on objects and custom actions need to occur.

For more information, refer to Execute Business Action Processing Plugin Parameters and Triggers documentation here or Execute Business Action for Event Batch Processing Plugin Parameters and Triggers documentation here.

  • Gateway Integration Endpoints - Accessed from JavaScript in business rule conditions and actions, the bind can work with a variety of the REST methods.

For more information, refer to the Gateway Integration Endpoint Bind documentation in the Resource Materials online help here. Gateway Integration Endpoints (GIEPs) do not always use the REST plugin; the Gateway Integration Endpoint Bind topic only applies for GIEPs that use the REST plugin.

  • Imports and Inbound Integration Endpoints - Conditions can be tested during imports, and the condition can allow or prevent the creation or update of objects. Actions executed during import can modify the objects being imported, apply actions to objects being imported, send emails, and start workflows, etc.

For more information, refer to Business Rules in an Import Configuration documentation here.

  • Matching, Linking, and Merging - Actions and Conditions can be used to normalize the data for comparison to identify the duplicate products in STEP. Actions can also be used in relation to Golden Records Survivorship Rules.

For more information, refer to Matching section of the JavaScript Binds topic in the online help Resource Materials documentation (here) or the Golden Records Survivorship Rules topic in the Matching, Linking, and Merging documentation (here).

  • Outbound Integration Endpoint - Conditions can be used as event filters for an event-based OIEP. Actions can be executed via a pre-processor for any OIEP, or as a event generator to generate derived events to export or publish for an event-based OIEP.

For more information, refer to OIEP - Event-Based - Event Triggering Definitions Tab documentation (here) or OIEP - Pre-processor - Business Action documentation (here).

  • Web UI - Actions can be executed to update the object. Conditions can be evaluated to improve data validity.

For more information, refer to Business Rules in Web UI documentation here.

  • Workflows - Conditions can be tested within workflows to allow or prevent transitions from one state to another. Actions can be executed when entering a state, when leaving a state, when performing a specific transition, and when a deadline is met. Actions can also modify the object being tracked by the workflow, modify other objects in STEP, modify the workflow behavior, send email, start other workflows, etc.

For more information, refer to Business Rules in Workflows documentation here.