In SharePoint, you can send email notifications when granting a user with access to SharePoint content. I have never been a big fan of this “Welcome Email.” The email is wordy, but often doesn’t provide enough context to users. Instead, I usually draft a personal email and notify the users separately.
Unfortunately, the “Welcome Email” option is selected by default. Easy to miss. So I have always encouraged users to be mindful and deselect this check box.
Recently, I had a front row seat of yet another great reason why we should all stay away from SharePoint welcome emails. A Site Manager had added a Domain Group to SharePoint but neglected to turn off welcome emails. Normally it wouldn’t be such a big deal, but in this case, the Domain Group added was comprised of over 10,000 users. What ensued is undoubtedly a memorable lessons learned – here’s a recap of how the day unfolded.
It all started with that Welcome Email [Names and references have been altered]
The team went proactive and tried recalling the message
Of course, it didn’t help and instead, the message went *viral*. Here’s a small sample size of the email traffic fiasco.
The Unsubscribe Me Group
The Angry Birds
The Good Citizen (note: singular tense is not a mistype)
The Clueless Bunch
The “I Will Get You to Stop “Reply All” By Replying to All”
So just to recap: Turn Off the SharePoint Welcome Emails.
You’ll thank me and this Site Manager later.
The Approval workflow in SharePoint has been helping teams automate business processes since the days of MOSS 2007 and WSS3.0. It is the most commonly used workflow and since it’s pre-built, SharePoint has done the heavy lifting so your setup time is greatly reduced. However, the Approval workflow can be a bane to many. On one hand, you can be up and running with just a few clicks; on the other, the out-of-box user experience may not be very intuitive for the users.
There’s certainly more than one way to skin this cat, but I find myself repeating a similar series of steps to enhance the experience. I look to document these steps before Microsoft officially upgrades my SharePoint Online environment to version 2013. I hope that, in the process, this post could also be useful to other SharePointers.
Before diving into the proposed solution, let’s first breakdown some of the challenges. Here’s my personal Top 5 Limitations of the SharePoint Approval Workflow:
- Inability to specify workflow condition
Applying workflow through the browser only provides you with the option to either start the workflow automatically or start it manually. You can’t conditionally design a parameter around how the workflow starts. For example, if you want the workflow to run only when a specific type of file is uploaded, you can’t do so through the browser.
- Potential governance concern
Users, who can manually start the workflow, can also change the workflow’s rule and designation. When teeing up a document for an approval, SharePoint allows for ad-hoc update to the workflow logic. Almost every makeup to the workflow (approvers, deadline, etc.) is up for grabs to everyone who has access to run it manually. This open-ended structure leaves you at the mercy of your users, who can accidentally (or not) change the most fundamental elements of the approval, thus altering the orientation of your business processes.
- Vague email notifications
The auto-generated emails from the Approval workflow often lack clarity. Upon receiving the email, users may not know how to move forward because the emails have duplicated info, ambiguous message, and most importantly, unclear instructions on how to approve the document. Users would be notified to “Perform specific activities required” without any other context.
Outlook integration feature – which could open the approval form from the email and is actually very helpful – gets lost in the mix because the language in the email makes no reference to Outlook. Users are simply instructed to “Use the Open this task button” – a “button” that’s located at the top of the email and is very easy to miss, especially in the Outlook preview pane.
- Due Date Duration not accounted for
There are 2 ways to set approval due dates – you can either assign an actual due date or specify a duration of the approval task. For the most part, the preference should be to set deadlines by duration so you don’t pin yourself down to one particular due date for all documents. Furthermore, should enough time passes by and your due date is in the past, SharePoint will display an error message to the user initiating the workflow.
Unfortunately, if you were to assign due date by duration, the approval workflow would not account for it. The system generated email would simply assign your due date with “None.”
- Rejected document marked as “Completed”
I saved the best for last, because this one trips me up the most. Receiving an email from the SharePoint library with a subject line of “Approval has completed” does NOT necessarily mean that your document has been approved. Your supervisor could very well have rejected your document and as long as all the required tasks are done, SharePoint deems the workflow as “completed.”
The body of the email doesn’t help the cause either by repeating such words as “approval,” “successfully,” “completed” to further mislead the user. Only if you were to look carefully, would you see 1 mention of the rejection buried in the middle of the email content. A definite flaw from a user experience design perspective.
Despite these challenges, I still believe that there are a lot of business values provided by the SharePoint Approval workflow. Thankfully, there are a few simple ways to overcome these shortcomings and I look to document these steps on my upcoming blog post.
Do you have other challenges with the workflow that’s been plaguing you? If so, please feel free to share your experience. Hopefully we can all compare notes on the implementation work-around and be more productive at the other end.
[Update: My next post in this approval workflow series is now available. Read the 5 Steps to Enhance SharePoint 2010 Approval Workflow]
In an SP2010 client environment, I have recently been encountering a slew of Check-In and Check-Out issues across separate libraries and site collections. The common scenario is a user checking out a file, then after working on the document and in the process of checking it back in, he/she would receive a SharePoint error. Discarding check out and going through the process again will yield the same result.
In my experience, a Check-In and Check-Out issue is typically a user error. So I would go through the normal verification process, i.e.:
- Does the user have the right permission?
- Is the user trying to check out a document that’s already checked out to another user?
- If the file’s checked out to a local SharePoint Draft folder, is the user trying to re-open the file on a different computer?
- Does this file have a previously checked-in version?
- Is it the same user login for both the computer and SharePoint?
- Etc. etc.
However, the troubleshooting sessions came to no avail.
Luck would have it though. With some persistence poking and prodding, the perpetrator is Long URL.
TechNet has notified us of the SharePoint limitation with long URL. As the article mentioned, Office Client can only consume a link with a max of 259 total characters. If you’re lucky, you might see this DDE error.
Sadly, the errors that my users were seeing had zero indication of long URL. So if you’re experiencing a similar issue with document collaboration, try putting URL length on your test radar. If that’s indeed your problem, you’ll need to cut down on the URL for your documents. Here’s a few things to minimize or preferably not have altogether in your SharePoint instance:
- Deep folder structure
In general, a good SharePoint implementation should have little to no folder on document libraries. If you must, try not going too deep. Each folders and subfolders are included in the filepath/URL, which gets you closer to the 259 max.
- Long Site or Document Library URL
Leave the descriptive context for the name/title. You want to be very careful at the time of creation, especially with Document Libraries, because you cannot change the URL to a library once it’s created. When you first create a document library, you want a short and concise name with no spaces (i.e.: “TeamDocuments”). Once it’s created, you can access Library Setting > Title, and change it something a bit more descriptive.
- Long naming convention
Much like site and library, filename also counts towards the URL total count. Beware of long winded filename.
- Managed Path
If you’re not familiar with Managed Path, it’s typically the “/sites/” after your sitename (i.e.: http://yoursite.com/sites/funwithmanagedpath). If you have a long Managed Path for your site collection, try working with your SharePoint administrators to create an Alternate Access Mapping, so you can start off with a shorter URL.
Of course there will always be another reason why Check-In/Check-Out isn’t working accordingly in your environment. But I hope that this scenario can help somebody out there, because it certainly got me scratching my head for a bit. Good luck!
When you add a list or library web part through the SharePoint UI, the web part title is automatically hyperlinked to the SharePoint list or library. For example, in the screenshot below, I have a standard Team Site homepage with a Shared Documents web part. The title of the web part is linked to the Shared Documents Library.
If you edit the web part, under the “Advanced” group, you will see Title URL where you can change the hyperlink of the web part title heading to another URL location.
However, if you decide to remove this Title URL value and click OK. SharePoint won’t allow the update. It would instead automatically re-enter the original URL value. To quickly get around that, Edit the Web Part and replace the URL with #
Once you click OK, you should be all set.
You may ask, “When do I ever need to do this?”
From my personal experience, this small tip might be helpful in a couple of ways. First, if you want to provide a specific view to a SharePoint audience. Hiding the link would allow you to highlight just the specified list view on the SharePoint page.
Another reason to remove Web Part Title URL is if you were to have a custom user permission level that restrict user to “View Application Pages”. The user would otherwise encounter an Access Denied page when clicking on that web part title heading.