Skip to content

Considerations Before Designing a Workflow

Following are the list of considerations that a user needs to be aware of before extensively working on workflows:

  • According to the Workflow transaction management policy, APIs that have implicit commits, rollbacks, savepoints, or Pragma Autonomous blocks, cannot be called through a Workflow.

  • Since Workflows execute on behalf of the user, the users who execute these Workflows should have the necessary permissions to access all the required projections invoked in that Workflow. Hence, consider all the users who are likely to execute a particular Workflow, and ensure they have grants to access the projections invoked in it. Without the necessary permissions granted to the user, the Workflow execution will fail.

  • Workflow User Forms cannot handle LOV (List of Values).

  • It is possible to add static enumeration to the Workflow User Form. However, enumerations defined in IFS Cloud are not supported currently in the Workflow User Form.

  • Authentication for Workflow IFS Rest Connector requires the Workflow author to create and manage authentication manually. It does not support OAuth authentication to create tokens when calling external APIs.

  • Blob, Clob, GIS, and File datatypes are supported only in cases where projections that manipulate them behind the scenes are called.

  • The Query Builder filter tool in IFS API Task supports Enum type attributes. However, it is important to note that it works with DB Enum value and not with client Enum value. Query Builder filter displays the client Enum value in the dropdown so it has to be changed to DB Enum value by modifying the filter text field value. For example, assume that the approval_status Enum attribute has its client value as APPROVED and DB value as APP. Then client value is displayed in the drop down as below.

    After submitting, it needs to be changed to DB Enum value as below to filter the record(s) correctly.

  • For a Workflow to be triggered from a Mobile App transaction, it must be fired asynchronously via a custom event.

  • Workflow only supports attributes that have a maximum character length of 2000.
  • In case there are a high number of workflows triggered simaltaneaously, when processing large volumes of data in situations such as Data Migration, it is recommended to disable these Workflows to avoid disruptions during the Data Migration process.

  • The maximum number of Workflows that can be executed in a single transaction is 20. This means if a certain action causes to execute 20 or more Workflow instances in a chained manner, it will give an error as "Potential infinite recursion detected in cascading BPAs". Suppose there are two Workflows, where one Workflow modifies all the customer order lines of a particular customer order, and the second Workflow is triggered for every line. This error will occur if there are 20 or more customer order lines in a single customer order. If there is a possibility of reaching 20 Workflows in a single transaction, the following actions can be taken:

    1. Use Asynchronous Workflow where this limitation will not exist.
    2. It is possible to override the default number of Workflows allowed in a transaction by adding a record to BPA_SYSTEM_SETTINGS_TAB. Add Variable as CASCADE_LIMIT and Value as a higher number that suits your scenario. Then restart the ODataProvider container.

    Note: Override the default value of this configuration responsibly since it might lead to transaction timeouts and performance issues, negatively impacting the system.