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