In screenshot the API task has the “Log Errors” option ticked on. When that option is enabled, workflow will not fail at that point and move forward with logging the error. The expectation is the user will handle the error inside the workflow and do the necessary actions.  If not, the workflow will continue and give a success message. 

Can you try unticking that option and see, then the exact error should be shown to the user triggering the workflow 

refer: IFS API - Technical Documentation For IFS Cloud

hi kamnlk,

Thanks for your response.

I tried it but it does not show the exact error. It gives the following generic error.
 

When I look at inspect, the correct error populates.

It seems like in this case the workflow is triggered using a Command button. When the workflow is triggered in that manner this generic message appears whenever something goes wrong with the workflow.

BPA called through button displays only generic error messages | IFS Community

If the errors, you are expecting in the workflow is somewhat known to you can set the Log Error option in the API task and then use a gateway to check the value of the error message and create ifs error end event with the relevant error message. In that way you can send the message you want to the user

eg:

Many thanks, I will try.

By this way, Can I show the original error message to the user? As long as I know, in the end error event only fixed message can be added.

Error end event can only put a fixed message, but as a workaround you can do something like; check the text on the error message as an extra condition for the gateway and put in that message as a hardcoded text in the error end event 

thank you, I will try and update here

Another couple things you can do:

Option 1

1. Refactor your method to have an out message variable (this likely means making a function call that calls your procedure and having the output of the procedure being the RETURN value of the function)
2. Change your Custom Method code to raise exceptions that set that message out variable rather than straight raising error_sys.record_general (This might be a problem if you’re calling this procedure anywhere else than in a workflow, see option 2 for more details)
3. Setup error_sys.record_general as a custom action on some projection (that projection needs to be active in API explorer obviously)
4. In your workflow, if your out message variable gets a result written back to it, through condition logic, just make a gateway condition that goes to an IFS API Call, calling the custom error_sys.record_general projection action, with the lu_name and err_text_ filled properly (i.e. using the output error message)

Option 2

I’m looking at your workflow, and it seems extremely simple (just a straight procedure call with an Order_No mapping). There is no reading or setting of variables. Despite this, you are calling it as a Custom Command (so a custom button in the client)

The question is why ? If you’re not going to use this workflow in anything ELSE than a custom command, you can simply add your procedure as a Custom Action to the Projection you’re going to use this command on, and then create a Custom Command that calls that procedure directly, with the required mappings ?

Here you’ll be able to simply call your procedure and map it, as long as your Custom Procedure has been properly created as a Custom Action for the Projection you’re on, and OrderNo is part of the context of the projection you’re triggering this from, which I assume must be the case as otherwise it wouldn’t be present as an Execution Variable in the workflow.

Here’s an example of a Custom Command in my environment doing exactly that:

This procedure has tons of validation with error_sys.Record_general handling, and it errors out with the right error messages just fine, for example:

Hi Simon,

Option 2 worked perfectly. Thank you!

Hi Simon,

Do you know if there is a possiblity to autorefresh the data? Now the user has to click refresh in order to see data changes after clicking command buttons.

I don’t believe that’s possible, I’ve looked for the same thing and came up short for my own needs, there doesn’t seem to be any current way to force a Refresh of the screen (or at least the entitySet being read) from BPA.

It’s a bit cumbersome because indeed it forces a user to refresh after you’ve clicked the command to show any updated data. Not super intuitive.

In Apps 10 for EE, the Custom Menus do have an option to force a client refresh on execution, but that isn’t present in Cloud at all for Custom Actions.

You can see this @kamnlk, who is an IFS Engineer, answered this question in this other community thread

Basically said as much :

I don’t know if it’s even technically possible at all for IFS to implement that based on their integration with Camunda, but it would be good to be able to do that (both for Workflows and for Custom Commands in general, like you could back in EE).

I would recommend that you raise this as an Idea (or reply to the Idea below, see details) to be potentially added to backlog, I would 100% support this myself. BPAs and Custom Actions are super powerful, but not being able to refresh the screen kind of diminishes its usability in certain scenarios where you update that in the same projection :)

Looking at this:

https://community.ifs.com/ideas/need%2Dability%2Dto%2Dsetup%2Da%2Dscreen%2Drefresh%2Dfollowing%2Dcustom%2Dcommand%2D15097

The idea has already been raised, but IFS says it’s not on the roadmap for now, so it might be good for you to reply to that and express interest (I might do the same as well)

thanks again I will create this as an idea

One thing, I edited my above reply, the idea already exists actually, so you can reply to it instead :)

done :)