cancel
Showing results for 
Search instead for 
Did you mean: 

Enhance Workflow so it may update disabled fields

Author Name: Robert BOYERS

Workflow cannot currently update fields that are set to disabled on a form. The workaround is to add script to set the field to be disabled so workflow may update it. As a customiser, I'm tired of having to do this and it also increases the performance overhead when loading a form.

I don't see the point of restricting workflow update steps from updating read only fields.
Pretty please, enable this and save all the customisers out there some precious time.

Status: Planned

Hello -

This is a good suggestion and something that we will look into adding to our future roadmap.

Regards,

Brandon

PM, Microsoft

Comments
D365Ideas_Admin
Regular Visitor
Status changed to: Planned

Hello -

This is a good suggestion and something that we will look into adding to our future roadmap.

Regards,

Brandon

PM, Microsoft

D365Ideas_Admin
Regular Visitor
For developers the is really anoying bekauce you often want to have fields which should be only updated by workflows but visible on the form. Users and especially non technically users as Sales PowerUsers don't understand why they can't update readonly field in workflows.
D365Ideas_Admin
Regular Visitor
Hi, 1) I have been using the workaround for 4 years, hence why I added this as a connect item because it's a pain to have to apply script simply to ensure a field is disabled so I can update it using a workflow's update step. We should be able to set the read only flag on the field's properties on the form and still be able to update it when in the workflow designer (update step). 2) I don't understand this sentence at all. Ok, to elaborate further, there are many situations when you may want to use a workflow to update a field which is presented to the user as read only. Wherever you are trying to automate a business process, you need your users to be able to view various pieces of information contained within fields but under no circumstances manually amend the data contained in those fields. Virtually every time you have an approval process, you would want a workflow to update an 'approved date' and 'approved by' value. Status reason is often updated via workflow, you need to display that on the form but you do not want users changing it. Simplistic autonumber generation would involve workflow incrementing the value of an integer field but again, you do not want end users modifying the field. A date field which is updated by a workflow to show the 'date next contact due' may increment and update this field by X months. Again, it is a field which the user would not be allowed to update. Is that now clear why this tweak would be useful? Thanks Rob
D365Ideas_Admin
Regular Visitor
Thanks for your suggestion. Like you mentioned, there are a couple of workarounds -1) You can use the onLoad event to disable the field 2) You can use different a form for user interaction where you disable/remove the field Can you elaborate on the actual end user scenario where you want the workflows to be able to update these fields but not in the form? Thanks Microsoft
D365Ideas_Admin
Regular Visitor
Rob - Thanks for the detailed response. We understand the pain point and will be considering this request for a future release. Thanks Microsoft.
D365Ideas_Admin
Regular Visitor
Still under consideration?
nickbr
Regular Visitor
There is a workaround that hasn't been tried yet: Microsoft implementing this request. 🙂
D365Ideas_Admin
Regular Visitor
Creating a second form that only admins can use, and making the field not read-only on that form works well. To write your workflow, open an example record, change forms so this is now your "Last used form", open workflow and edit the create/update record steps and it will use the current (unlocked) form. I can see that in some environments, it is desirable to let some users create workflows. If they could globally overwrite fields that were otherwise read-only, using an on-demand workflow, this sounds dangerous to me. So perhaps the funationality needs to be controlled by a special privilege "Can overwrite read-only fields in Workflow editor", off by default for all but system admin / customizer
D365Ideas_Admin
Regular Visitor
Thanks for the comment Adam. Having to remember to switch forms or have a system admin accessible form with enabled fields is still a pain IMO. I understand your comment in terms of updating a disabled field as being dangerous but I would counter by saying workflow is commonly used to update disabled fields because you want automation and not a user to populate the data in the disabled field to guarantee consistency. I know Microsoft see the flexibility of allowing end users to create their own workflows as a selling point but in the vast majority of deployments (except those with a handful of users), it is usually the job of the system administrator to construct the workflow who 'should' know what they are doing when updating a disabled field. I'd vote for your suggestion to add a privilege to security to appease both arguments.. I'm not holding my breath however 😉