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.

  • If an attribute is NOT defined as ‘updatable’, it cannot be enriched or assigned a value by a process enrichment task. This applies even when an insertion of a record triggers the Workflow. Although it seems that the attribute is being inserted for the first time rather than updated, if the attribute is non-updatable, the value still will not be saved.

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

  • When a client calls an API, the OData Provider includes a built-in mechanism to refresh its metadata cache. This ensures that if the API is modified, the cache is updated, allowing new values to be retrieved. However, when an API is called through Workflows, the cache is not refreshed. This can lead to metadata errors due to changes in the API not being reflected in the cache. The reason for this issue is that the Workflow architecture operates later in the HTTP request lifecycle of the OData Provider, while the metadata cache refresh occurs at an earlier stage. >Note: The workaround to avoid this error in case an API has changes to its metadata and needs to be used within a Workflow, is to first make the HTTP call to the projection which will trigger the metadata cache refresh, and then call it in the Workflow.