TRIRIGA

Hey Lee,

You are correct in that you can't delete a field if it is in use. However, the usage is limited mainly to usage in a Form. It does not block you if it is used by workflow. As a best practice you should always do a where used on the field and then remove its usage first, and then finally delete it.  The issue you are seeing comes down to the fact that there is no validation for workflow mappings. There is a table in the database that contains the mappings. It is a pretty straight forward table in that it has the BO Id and the Field Id along with the mapping information. The platform however does not look at the BO Id in this table but instead uses the BO Id of the corresponding Task. So when a field is deleted from a BO or workflow is copied, or the underlying object of a workflow task is changed, this mapping table doesn't update or validate and remove bad mappings. There are actually thousands of mappings in the mappings table that are currently invalid. So if you create/add a field to a BO and that field's Id happens to match up to the field Id on one of these mappings it is going to think it is a valid mapping. Another thing is the where used functionality scans this mapping table and uses the BO id in it, whereas the workflow actually maps based off of the task Id.  Here is a link to an article I wrote several years ago that documents this: https://www.linkedin.com/pulse/hidden-danger-copying-tririga-workflows-mark-johnson

The where used functionality will also check for all versions of a workflow that exists in the system. If you look where you highlighted the link in the where used the first number is the workflow template id 49860475 and if you look at the url in the header of the workflow you'll see after the jsp?wftid=49860475. So based on the information the correct workflow is being opened. If I had to guess I'd say that the workflow has been renamed from a previous version. Go to the workflow builder tool and select the workflow and then click the List All Revisions link to see all the previous versions of the workflow. So a scenario where the workflow had been renamed and there was a bad mapping in the previous version of the workflow that suddenly became valid upon adding the new field to the BO would explain this situation.

--Mark

Original Message:
Sent: Fri December 06, 2024 03:42 PM
From: Lee Jarvis
Subject: An unusual problem with workflows

I've been troubleshooting an issue with a workflow and discovered something strange that I can't explain or resolve.

 

The workflow was failing and generating an error because it referenced a field that no longer existed in the business object. This field had been removed several weeks ago. This leads to my first question: I remember that when attempting to delete a field from a business object, the operation would fail with a warning if the field was referenced in any form, query, workflow, etc. However, I have since verified that I can delete a field from a business object even if it is still referenced in multiple locations. Am I misremembering? Shouldn't I be prevented from removing a field that is still in use elsewhere?

 

To continue troubleshooting, I added the previously removed field back to the business object (but did not publish it yet). I then clicked on "Where used" and immediately saw that the field I just re-added was referenced in several places, including a couple of workflows. Here's where it gets really strange: The hyperlink doesn't point to the actual workflow it references! What is going on here?

 

Thanks and regards,

Lee Jarvis

Publix Super Markets, Inc.