Let’s admit it. Sometimes things just go wrong and you need an easy or straight forward way of cleaning it up and starting over again. An example of this happened to me the other day where I had a bad workflow that went unnoticed and started suspending. By the time it was noticed there were about 50+ suspended workflows (it was an active list). So after stopping the workflow I started working through cleaning it up and thought there has to be a way to terminate SharePoint 2013 workflows with PowerShell. Turns out I could do it. Here’s how:
A question I get often, especially around solutions where security is a big concern is “how can we see who looked\opened\updated\deleted an item in our document library. Updates, are easy if you have versioning enabled as it tracks each update in the version history, but what if you don’t want versioning enabled or you need to track the other items? Enter SharePoint audit reports. I previously blogged a detailed post on the audit logs within SharePoint. Basically, once enabled they will record everything that occurs within the site depending on the settings you select. You can find more information on it here. However, the problem with audit reports is you need site collection admin access to see them. This does not work in many instances as most end users don’t (and shouldn’t) have that level of access to your site collection. So how do you get them the reports without manually running the report for them each time they require it? This is what we are going to cover in this series. This post specifically will assist you in preparing the data for your users from the SharePoint GUI.
Quick Note: this may be an old topic, in fact I know it is. I started this blog two years ago and apparently forgot about it. I was going to trash it when I came across it but remembered that I still see a number of requests for setting up audit reports to automatically run for others. So I decided to complete it since it is still relevant for all versions of SharePoint including SharePoint Online
I had a great time recently presenting at CalSpoug’s SharePoint Saturday. The first session I presented was on SharePoint Business Connectivity Service. I have done this session quite a few times and I always have at least one attendee state they have never heard of BCS before. This session was no different. One of the things I cover is the importance of BCS in different environments. Many will argue it is an old, unnecessary system. I do not necessarily disagree with this. However, I argue it isn’t dead yet. If you are working with simple data in a SQL Database or even more complex but well-organized data in a database the ease of use within BCS is quickly seen. In 5-10 minutes you can connect to your data and present it within SharePoint utilizing built-in forms (no custom form development). Users will be able to read and update the data immediately (assuming permissions are configured already). There’s more to it than just this and you can take a look at my slide deck to see.
Having said that, I do believe that I see an end to BCS. PowerApps and Flows make accessing data just as easy and more configurable through the many, many connectors available. As these connectors mature and the tools grow, the use cases for BCS will slowly disappear. However, we aren’t there yet. BCS is still there and still very easy to use.
Take a look at my slide deck and if you have questions, please reach out.
Thanks for reading!
Something that I have come across a lot is solutions that require setting item level security after a particular occurrence on the list item (or in some workflow process). Specifically what I wanted to look at was how to do it using SharePoint Groups as opposed to AD users, though I will probably cover that later. This is going to be a two-part post as well because I am also going to do it with Microsoft Flow in my next blog. Moving forward, whenever I do a SharePoint Designer Workflow blog I am going to try and do a corresponding one for Flow as well.
I am sure we can all agree that at some point or another we had a need to email a user that did not have an account within our domain via a SharePoint Designer (SPD) 2013 workflow. And while attempting to set it up we were surprised to find out it wouldn’t work. Not only did it NOT send the email, but to add insult to injury the attempt actually would suspend the workflow if forced to try. If you have never had the need, well thanks for coming to my post anyways and let me tell you… it can’t be done. An easy workaround is to build a SharePoint 2010 workflow, which doesn’t have this limitation, but then you lose the other fantastic benefits of a 2013 workflow. Microsoft removed this ability as a security enhancement. Today I am going to demonstrate how to email an external user in a SharePoint 2013 Workflow.
Quick note: Microsoft Flow does NOT have this limitation. I am describing how to to it in SharePoint Designer because so many still use this tool