Victor Posted August 31, 2018 Share Posted August 31, 2018 Most common scenarios that will cause an error in the workflow/business process as a result of incorrect configuration Link to comment Share on other sites More sharing options...
Steve Giller Posted February 17, 2020 Share Posted February 17, 2020 During a Business Processes you encounter a Flowcode error where the error message contains: "Uncaught TypeError: Cannot read property 'outcome' of null" when trying to use the outputs from a Task. This is most commonly encountered when the node has been copied, and when pasted the node variables have not been updated, so the node is trying to use the outcome from the wrong task. Link to comment Share on other sites More sharing options...
Steve Giller Posted February 17, 2020 Share Posted February 17, 2020 When the Business Process tries to create a Human Task the error "The specified user 'SYS_BPM_MANAGER' does not exist" is generated. This indicates that the System does not recognise the User assigned - this can refer to the Task Owner or the User that you wish to assign the Task to. Most common scenario is when the Variable used is "Owner" as the "Owner (For Tasks)" is the required value. In the Human Task settings pictured below, the Owner Variable is set correctly using Owner (For Tasks), but the Assign To Variable is set incorrectly using Owner. This can also be caused when there is currently no Owner assigned to the Request or when the referenced variable has no value (e.g. a custom field that is empty) Note: The value of Owner is populated by the the Get Request Information -- RequestDetails node. If your Request is generating this error when there is an Owner assigned to the Request (or if you are seeing the Task assigned to the "wrong" Owner) you may need a new RequestDetails node to refresh the information immediately before creating your task. Any manual actions applied to the task will not automatically be picked up by the Process, so if a User manually assigns the Request to an Owner the Process will not be aware of the new Owner until a Get Request Information -- RequestDetails node is passed through. Link to comment Share on other sites More sharing options...
Steve Giller Posted February 18, 2020 Share Posted February 18, 2020 If your Business Process presents you with a 'No matching gotoIf' error this means that none of the branches from the decision node have matched. In the example below, the decision node has branches for Custom30 having values of 1, 2, or 3. If the Custom30 field has a value of anything other than 1, 2, or 3 when it reaches the decision node you will see the error above. The most common reason for seeing this error is when you have a branch for 'is set' and another for 'is not set' which you would expect to cover all possibilities. However, in a database, a 'null' value is neither 'set' nor 'not set', so you need the 'No Match' option as a third branch. Another is that the Process has not yet confirmed the values - e.g. using the Owner variable without a Get Request Details node. It is strongly recommended that every Decision node has a 'No Match' exit. Even if you think that a Process can never arrive at the Decision node without matching one of your exit conditions you should always cater for the possibility that it does not - it is better to have a branch that is never used than to encounter an unexpected error. With this in mind the above setup would correctly be set up like this: Link to comment Share on other sites More sharing options...
Steve Giller Posted February 18, 2020 Share Posted February 18, 2020 Process::Execute: exceeding maximum step count (1000)... If the Business Process finds itself in a loop, it will eventually produce this error. This is normally due to the configuration of a Decision Node which is directing the Process back to a previous node. The most common reason is an unexpected value that has not been catered for causing the Process to take the looping branch rather than the branch that moves forward. Examples might be case-sensitive values (e.g. Success is not always the same as success) or a NULL value where you're testing for a blank value. If you do need to branch back to an earlier node, always do so based on a testable value, it is always inviting this scenario if you are branching backwards on the "No Match" condition. Link to comment Share on other sites More sharing options...
Recommended Posts