Locking fields based on task status

[RobSt]

Hi Community! Hope you can help me.

I am looking to lock specific fields based on the status of a (sub-)task. These concern fields on project and/or (sub-task) level. But I cannot find anything about this in the documentation, other than creating a scenario in Fusion to undo changes I values are changed, which is not acceptable for our setup.

Is there anyway to lock the values of fields based on (sub-)task status? Instead of locking, potentially using the 'Display or Skip' logic rules can be used based on (sub-)task status? Open to those kind of opportunities as well, of course.

And if not, should I add this as an idea? And would you be willing to vote for that?

[Kurt_Jones]

RobSt -

I'm not sure what object this form is sitting on but have you considered using business rules?  Those can be triggered on edits to check data and provide message to user why info cant be updated...just a thought.

[RobSt]

Thx a lot for the suggestion @Kurt_Jones. Appreciated! And yes, if these rules would generally apply this would work. But in our use case it is not a generic rule for all (ie) projects/tasks at any given time. Hence why the current capabilities within business rules is not sufficient to cover our ask. If you could use (ie) AND/OR statements and combine conditions.

So for our query the current capabilities of business rules it is not bringing a solution. Thank you for the suggestion!

[kautuk_sahni]

@RobSt Just checking in — were you able to resolve your issue? We’d love to hear how things worked out. If the suggestions above helped, marking a response as correct can guide others with similar questions. And if you found another solution, feel free to share it — your insights could really benefit the community. Thanks again for being part of the conversation!

[RobSt]

Hi @kautuk_sahni! Appreciate the check, and we have validated this proposal. But we could not get this to work with multiple filters (AND/OR statements). This is needed to reduce the system-wide impact of using rules.

So, as in my reply to Kurt, this is not a working solution for our specific use case. Hence why I haven't confirmed 'Correct reply'.