1

I maintain a SharePoint list/site used by members of multiple teams. The overall point of the list and site is for members of team A to add action items that will be assigned and dispositioned by members of team B.

I've added a workflow to the list, running whenever an item is edited. The details of the workflow are not important (or shouldn't be...). However, since I both maintain the list and use it as a member of team A, sometimes I want the workflow to fire (as an end user) and sometimes I don't (when I'm cleaning things up).

In the past I had opened up SPD and simply disabled the worfklow from running on edit, which works. But I live in fear I'll forget to re-enable it when I'm done maintaining and cleaning up. So I'd like to provide a "kill-switch" of sorts that lets me halt a workflow early.

I thought the below picture would work: check to see if "ADMIN" is entered in a certain field. If it is, re-set the field's value to what was previously entered, send me an email notifying me the workflow was overridden (in case someone else accidentally enters "ADMIN," at least I'll know), and then log the override while stopping the workflow. (Non-relevant personal details have been redacted from the screenshot.)

The first time I did this, it worked as intended. I've since done it twice more and both times the rest of the workflow triggered, causing confusion.

Workflow illustration

Two questions:

  1. Can anyone diagnose why the workflow is continuing to run even though it should be stopping, and
  2. Can anyone provide a better "optional over-ride" mechanism? I don't want it to be triggered by anyone else accidentally, so adding a visible checkbox or field on the "Edit Item" form isn't ideal.

Potentially helpful: The "Latest Update" field referenced in the workflow is a full-HTML field with markup allowed, but each of the three times mentioned in the question I have taken care that the only text submitted was ADMIN with no HTML formatting tags.

0

In an HTML field, even if you've entered only plain text, it's typically surrounded with <p> or <div> tags. If you look at the list item data from the web service side, you'll see this. Or if you click into the field you'll find a "source" button in the ribbon you can view as well.

You would be better off using a plain text field to look for a string match, or check to see if the field contains (instead of equals) a string, though probably something much more obscure than just admin so another user doesn't accidentally cause the WF to not fire.

  • I'll double check this, but for each of the three times mentioned I edited the markup version of the field to verify that there weren't any <p> or <div> tags. You're right that "contains" is a better approach, though. I don't really have any plaintext fields to work with, so I'll try to use "contains" with an obscure string to better prevent accidental overrides. – mikstravaganza Jan 22 '18 at 17:39
  • A quick and dirty way is to look at the item via REST, just by dropping something like this into your URL (where "123" is the item ID in this case -- and update the other fields as necessary): path/to/your/site/_api/web/lists/getByTitle('XX Marketing External')/Items(123)?$select=ID,Title,Latest_x0020_Update – Chris Romp Jan 22 '18 at 17:41
  • I also love this Chrome extension for "peeking" into your SP data. Could be useful in this case to see what's going on in that field. chrome.google.com/webstore/detail/sp-insider/… – Chris Romp Jan 22 '18 at 17:42
  • Super helpful comments, thank you Chris Romp! Using "contains" appears to have fixed the issue; it's possible there was more going on under the hood than just manually inspecting the markup revealed. So far, 8 more overrides have been successful and 0 triggered the WF to run unexpectedly. I'm going to mark your answer as accepted. – mikstravaganza Jan 22 '18 at 20:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.