Hello Harry,

It seems like something might be out of sync, for example a task parameter to table link that is missing from the application's model. Have you tried re-synchronizing your application to the IAM that you're using, just to be sure that this is not the issue?

Hi Renée, 

Yes I've tried syncing but the issue is still occurring. What I think is causing the issue is the fact that the user has a records selected (since he needed to double click it to trigger the task) and when the task is executed, the selected record get's deleted. This is reflected by the message stating that the object was not found, however for our end-users this does not make any sense so we'd like to suppress the message. 

Unfortunately I don’t know then. I am not part of the Indicium or Universal team so I have no detailed insights into what could be causing this issue. I can only reason from the perspective of my knowledge of SF/IAM models and possible origins for this problem from that perspective.

Hopefully you will be able to find the answer to your question :)

@Vincent Doppenberg Any insights on whether we can suppress this error if it is actually intended to get this record deleted?

I am having an issue like this too

@HarryA We were having the same issue. We solved it by incorporating the task in a process flow, which then closes the document and reopens it again. This way you don’t get the error message and the user can go on and select the next record.

It would be helpful to get some more information about the API call that causes a 404 error code and subsequently causes this message to be shown.

This information can be found in the browsers’ developer tools, more info here.

For instance, the configured refresh action of the double-click task may influence this behavior. If the task is configured to refresh the selected row after execution and the selected row has been removed from the overview due to the execution, a message like this could be expected.

@Allard Lakerveld Hi Allard,

Thank you for the suggestion. Opening and closing the whole document in our situation is unpredictable for the end-user in our case so I do not think that is the way to go for us.

@Anne Buit Hi Anne,

The API call that causes the 404 error is the stage_edit call. The Request URL is: ‘iApplication]/calculation_component_overview.contract_calculation_overview(calculation_id=13531,calculation_component_id=107491,grouped_component=false)/stage_edit’

I’ve checked the refresh setting, the task has Subject as Refresh after Execute configured. 

Please let me know if I can supply additional information to give a better insight into the problem

Hi Harry,

This is quite a specific scenario but it looks like the selected record in calculation_component_overview no longer exists with the primary key values after executing the task.

Does the task edit any data? Even if so, the chance for this should be quite low - the task-configured refresh after the (double-click) task should ensure the record is up-to-date.

There may be an issue where the ‘Edit row’ is initiated before the task-configured refresh by the double-click is performed. This could be verified by looking at the HTTP log or you could add a ‘Refresh subject’ process action after the task to further ensure a refresh is done before the ‘Edit row’.

Hi @Anne Buit, 

Thanks for the swift response! I’ve added a screenshot from the calls below, so if I understand you correctly the issue is being caused by the two calls that happen before the change detection? 

Hi Harry,

The most interesting part is what happens before the 404.

I’m assuming the task causes the key of the selected record to change or causes the selected record to become unavailable to the user somehow. The question is whether or not the data is refreshed between the task execution and the subsequent edit the current record instruction by the process flow.

We had the same issue but in our case refresh after execute was set to subject so we changed it to none and made a procesflow which refreshed the parent first then the child and that made it go away
 

Hi Anne,

This time the screenshot of all the HTTP calls after te commit  But as shown I do not think it gets refreshed

Hi Thimothy, 

Thanks for your reply unfortunately even if I only set the refresh after execute to none, it still shows the message. 

I’ve added some further screenshots to give a better insight in the situation

FYI: after further investigation we found that Auto-edit somehow was still enabled on the Variant, while Edit was disabled (and thus causing the setting no longer be visible in the SF). After disabling the setting, our error is gone.

For the SF issue we raised TCP 7209. 

Just as potential additional reason the situation might occur is when something in the record has changed (like a state) which places the record outside of the prefilter condition.