Have you ever tried to delete a field or state in Composer and discovered that you can only 'soft' delete it? This occurs because once a process app has been published, Composer prevents you from making changes in the process app that cannot take effect at runtime. Below, we discuss why this is, and what you can do to get around it when you need to.
Your SBM runtime data (the records in your primary and secondary tables) represent the essence of the work in your business processes. This is true both for active items which represent work currently underway, and inactive items, which represent the history of the work your team has performed. We'll start by discussing what happens with this data when you change the definition of the process.
There generally aren't issues with existing data when you add something to a process. For example, when you use Composer to add a field to a table, then deploy the process app to an environment, the value of that field in existing records will be empty, unless you have specified a default value for the field (property editor, Attributes Tab) and checked the Backfill to existing items checkbox. If you add a new state to a process, no problem. Existing items all reside in some state in the process. None will reside in the new state until you transition them to that state.
On the other hand, when you delete a field or a state, there are a few hazards to the existing data that need to be navigated. For example, if you were able to completely delete a state, what would happen to all the items that currently reside in that state? If you deleted a field (a column from the database) every bit of data in that field in existing records would disappear, you'd lose current and historical data. Reports that referenced that data would break. Audits that relied on that information would fail. So any physical deletion of states and fields is not a good thing. To address these types of problems, SBM (and TeamTrack before it) has never allowed states and fields to be completely deleted from the Application Engine. Instead, states and fields are marked as deleted, but remain in the database.
The ideal goal is for Composer to prevent the deletion of a state or field that already exists in runtime, showing it as soft deleted and providing a restore option. This would allow the design environment to accurately reflect which changes can and cannot be made to the design. The dilemma is that Composer doesn't (and can't) know which environment the process app will ultimately be deployed to, nor does it have information about the fields and states in that environment, so it can't accurately do this.
So, instead, Composer permits only soft-deletion of design elements like states and fields after a process app has been published (i.e. sent to the Application Repository). Some other similar data, like internal names for workflows, states and transitions, become uneditable.
There are times when this approach doesn't make sense. For example, if a state or transition was mistakenly added to a process app, and that process app has been published, but not deployed, or was deployed to an environment other than the production environment, the publish restrictions prevent the error from being corrected. In the past, our advice was to export the process app to a blueprint, then re-import it into Composer. This would remove all restrictions.
In SBM 10.1.3, we simplified this by adding the ability to directly remove publishing restrictions from a process app. To do this, open the process app editor by clicking on the process app in the application explorer:
After clicking on the Remove publish restrictions button, you will see a warning dialog. Click Yes to remove the restrictions.
If you enjoyed reading this blog entry, please subscribe to my blog by clicking the 'subscribe to updates from author' link below.