In two new kalmstrom.com Tips articles I describe how unwanted column changes can be rolled back with a flow or workflow.
Protect column values
By default, SharePoint users have Edit permission over lists and libraries, and that allows them to change column values. Users must have this permission level to be able to work actively with the content, but this means that they also can change column values that should be kept as they are. It is possible to restrict their access to certain items or documents, but it is not possible to restrict access at column level.
I therefore suggest a workflow or flow that simply rolls back any changes in the column that should be protected. This does not stop the column value from being changed, but as the unwanted change starts the flow/workflow and the change is rolled back, no harm is actually done. Any changes can still be seen in the version history, if you want to track them.
Set original column value
The process is similar for both automation methods. We assume that the first value that was added to the column is the original one, that should be kept. The first step is therefore to decide what that value is and save it in another, hidden, column.
Check if the value has been changed
Next step, is to decide if the column that should be protected has been changed. If that condition is true, the flow/workflow will roll back the modification so that the changed column gets the value from the hidden column.
Workflow
To automate this process in SharePoint Designer, I recommend creating two workflows: one that runs at creation and sets the original value and one that runs at changes and rolls back any modifications of the protected column.
Flow
If you prefer to use a flow for the roll-back process, it becomes a bit more complicated. That is because Microsoft Flow does not (yet) have the SharePoint trigger "when an item is modified".
Instead, we have to use the trigger "when an item is created or modified" and make the flow understand if there has been a creation or a modification. We can do that with a condition that checks if there is a "null" value or not. SharePoint columns have such a value before they are used for the first time.
Microsoft has created Flow to have a more user friendly alternative to workflows. In this case, however, I find the two workflows easier to build than the single flow. I hope that Microsoft will add the SharePoint trigger "when an item is modified" to Flow in a near future.
By Peter Kalmström
CEO and Systems Designer
kalmstrom.com Business Solutions
Protect column values
By default, SharePoint users have Edit permission over lists and libraries, and that allows them to change column values. Users must have this permission level to be able to work actively with the content, but this means that they also can change column values that should be kept as they are. It is possible to restrict their access to certain items or documents, but it is not possible to restrict access at column level.I therefore suggest a workflow or flow that simply rolls back any changes in the column that should be protected. This does not stop the column value from being changed, but as the unwanted change starts the flow/workflow and the change is rolled back, no harm is actually done. Any changes can still be seen in the version history, if you want to track them.Set original column value
The process is similar for both automation methods. We assume that the first value that was added to the column is the original one, that should be kept. The first step is therefore to decide what that value is and save it in another, hidden, column.
Check if the value has been changed
Next step, is to decide if the column that should be protected has been changed. If that condition is true, the flow/workflow will roll back the modification so that the changed column gets the value from the hidden column.
Workflow
To automate this process in SharePoint Designer, I recommend creating two workflows: one that runs at creation and sets the original value and one that runs at changes and rolls back any modifications of the protected column.
Flow
If you prefer to use a flow for the roll-back process, it becomes a bit more complicated. That is because Microsoft Flow does not (yet) have the SharePoint trigger "when an item is modified".
Instead, we have to use the trigger "when an item is created or modified" and make the flow understand if there has been a creation or a modification. We can do that with a condition that checks if there is a "null" value or not. SharePoint columns have such a value before they are used for the first time.
Microsoft has created Flow to have a more user friendly alternative to workflows. In this case, however, I find the two workflows easier to build than the single flow. I hope that Microsoft will add the SharePoint trigger "when an item is modified" to Flow in a near future.
By Peter Kalmström
CEO and Systems Designer
kalmstrom.com Business Solutions
In February 2009 I hired a young but very capable developer for the kalmstrom.com products. Today he is my friend and business partner, and I owe him a lot. His name is Jayant Rimza, and since 2010 he has been the director of the kalmstrom.com Indore office.
As more customers spread the word about kalmstrom.com Business Solutions, there was a demand for custom solutions and support contracts as well. Today, these 
