Organizations update procedures and documentation at an alarming rate, sometimes it’s rubbish and other times it’s important information to get out to your customers. For those orgs that have a sound process of documentation within their ITSM this may or may not apply, but I’ve yet to see these types of communications work really well. In this article, I will discuss principles to implement a good change communication workflow for SharePoint, but in a way that could be relatable to other knowledge base like platforms. Let’s get automating!

OK, so every so often we want to send out a summary to our customers to inform them of some significant change in our environment. Decide what often means and set an Add to Time action. This is an important step, as we will refer to this over a few times to set parameters on the time range in which we want to report. This will become clearer later. For me this is 2 weeks, so I will add -2 to utcNow()

Now we are ready to pull in our data. For me this will be a SharePoint List, but really this can be just about any data source as long as you have the following info:

• Modification Date – This is really the only critical piece. We need this to check against our window.
• Significant Update Bool – What is considered important to relay to the audience?
• Update Description – Save the users the time of reading. Summarize the significant change.

I filtered out the data right in the GET. Notice for created and modified I reference my Add to time body.

As a side note if you don’t see the visual filter query like the one I have above you may need to turn on Experimental Settings. Cogwheel in the upper right.

New we can start to construct our table. Use the select and compose actions to get a basic HTML table going.

Compose back into into another HTML sheet if you want to beautify it. You can find editors all over the Googs.

Now that the data has been attained we can just plop it in a vehicle, right? Well sorta of, give it a whirl and you will see we have some funky HTML going in. Therefore whatever you decide to do, it probably isn’t going to be exactly what you had in mind. See below for the replace expression to help PA get unconfused. Go check out some examples of the replace function if you are confused as PA was when introduce our table, but essentially we are using this to clean up some items that are being misinterpreted. So here, we are creating an HTML doc that lists our changes in a nice and neat table.

At this point our automation is pretty much complete, but we need to reset our filter for each record that was set as a “Significant Update. We don’t technically need to do this but it sets thing up for additional changes later and helps a bit with human error (not resetting the filter to the default “No”). If we examine our GET filter, it needs to see both a YES for significant update and be in the modification/created window so, this again is just a nice thing to reset it so we dont get false positives from someone leaving this unchecked. We also want to now communicate out that the documents have been checked and a file with the summary has been created Only if its not empty. Otherwise we will just log an empty file that indicates such.

Lastly let’s send off a Teams message if there were changes and replace the blank HTML file if the content length is 0.

Again, for this article we used SharePoint as our data source, but this could easily be done with a true ITSM relying on API’s specific to that data source instead.

“Sometimes it’s a little better to travel than to arrive”

― Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values