Skip to main content

I have two lists.  List #1 contains 10 meters and we want to track when the meters are moved from one location to another.  When a user changes the location of a meter, it kicks off a workflow to create a new item in List #2 and a workflow from List #2 begins.  

 

The issue I'm having is if meter #1 from the first list currently has a workflow running on List #2 - then I don't want the user to be able to change the location for that piece of equipment.  How can I solve this issue and keep the end user from editing a list item that has a workflow running on List #2?  Should I do this through Item Permissions in a workflow on List #2?

 

Any ideas???

Does this sounds like a possible solution to try

  • In list 1 workflow, just before the Start a Workflow action, have an Action Set with the Set Permission action, start workflow action, then set Permissions action within it
  • The Action Set should be set to Run as Owner (which is the workflow publisher)
    • This is to allow the permissions to be changed and changed back again regardless of the initiator
    • In the Set Permissions, change the permissions of the appropriate groups to read on the first action
    • Set the permission back in the second Set Permissions action

You can do it with a simple Status field.

 

On the List 1, you can add a status that you set to something like "Piece in relocation" whenever you launch your list 2 WF, then this status is set back to "Piece operational" when the List2 WF is completed.

 

Then on your List1 Form, you just have to test this status and to create a rule on your location field that disable the field if the status is set to "Piece in relocation". It would mean that your list 1 item would still be updatable, but this particular field will be locked


Sounds like this might work! How do I create a rule on the location field?


Here is the process :

  1. Select your field,
  2. On the ribbon, click on the "Add Rule" Button
  3. Create the rule :
    • rule type:  formatting
    • Condition : isNullOrEmpty(YOUR_FIELD) (to get the "isNullOrEmpty" function, go in the Runtime functions tab)
    • Thick the "Disable" checkbox
  4. Save
  5. This is it!!

Love this method Alex! Works best because this will increase the speed of the workflow making it less complex and still provide the same result!


Thank you so much Alexandre for your suggestions and quick responses. I've been trying various scenarios for the past couple of weeks and I'm still having issues. 

I created a Status field for List 1.  List 1 workflow sets the status to "In Progress".

List 2 sets the status to "Completed" at the end of its workflow.

I then created a validation rule for List 1 in list settings, based on the Status column:  = Status]="Completed"

So the validation rule keeps the item from being edited it the Status column says anything but "Completed".  The issue then is that the workflow for List 2 cannot update the Status column in List 1 to say Completed, because my validation rule has it locked down.

Do you have any ideas on my validation rule, so I can make the item editable again?

I've also tried changing the item permissions in the workflow for List 2 - set to Read at the beginning of the workflow and then changed back to Contribute at the end of the workflow.  This also hasn't worked.  The workflow sets the permissions to Read but errors when trying to change it back.


This issue has been resolved!!!

I just needed to change the validation rule on the location column to [Status]!="Completed" and checkmark Disable.  I had previously tried a variation of that rule in List Settings>Validation and I had tried the rule suggested by Alexandre Joly in the form itself on the location column.  Adding gStatus]!="Completed" to the location column fixed the issue and it works like a charm.

With that rule applied, it locks down the location column and the end user cannot change the location (thus kicking off another workflow) unless the status column has been updated to completed.  Thanks everyone for your help and thanks to Vadim Tabakman for figuring out the rule to apply.


Reply