If you’ve created a workflow in SharePoint Designer and an email action appears to be configured correctly, but emails aren’t being sent to some individuals in the To: line, you may need to turn the email being used into a workflow variable and use that instead of direct addition to the To: line of the email step.
This often happens for group email inboxes or external recipients that aren’t just a “normal user.” If there is a mix of recipients, some may receive the message but the troublesome addresses don’t even appear in the To: line, as if they’re removed before sending.
To “variablize” an email (this is using a SP 2010 platform workflow type):
1. Set a new workflow variable of type string to the email address(es) that aren’t receiving emails as expected.
Click to enlargeClick to enlargeClick to enlarge
2. Now in your email settings, use the “Workflow Lookup for a User” option and select your new variable from “Workflow Variables and Parameters” data source.
Imagine getting an email with a direct link to review the version history of an item or file. Or being able to have a single click from a list view to an item’s version history without going through menus.
The link itself is easy to structure manually. You could also structure it automatically using SharePoint Designer workflows or Power Automate flows.
No matter your method, you’ll need to be able to get two pieces of information: the list GUID and the item/file ID.
Getting required info
Get the list GUID
The list GUID is easy to get. Just go to the list –> List Settings and copy everything in the URL after List=.
In SharePoint Designer or Power Automate, you can just use the ID field provided as a lookup option. This way it’s always dynamic.
But to get the ID manually without workflow, view/open the item and check the end of the URL: for the number following “ID=”. Example:
http://SiteURL/ListName/DispForm.aspx?ID=532
For document libraries, or if you’re using modal dialogs (pop-ups), your URL won’t show ID. In this case, you can add the default ID column to your list view to get it.
Tip: For list items (not documents) you can also hover your pointer over the link to the item to see the URL preview at the bottom of your browser before clicking it.
Building the link
Manually construct it
The basic structure, no matter which method you use, is as follows:
Just replace the SiteURL, list GUID, and item/file ID.
Tip: The easiest way may be to copy the entire URL when getting the list GUID, change listedit to versions, and add &ID=ID to the end.
Use SharePoint Designer
In SharePoint Designer, you can use String Builder when creating hyperlinks in emails, or when populating fields (such as a hyperlink column).
Click to enlarge
Use Power Automate
In Power Automate, you can initialize a variable to structure the version history URL so that you can use it repeatedly in different steps/conditions without having to structure it every time. We do this similarly to how we did for SharePoint Designer above. Type almost the entire URL which doesn’t change, then use the dynamic content panel to add ID to the end.
Click to enlarge
Then you can send an email and use a little code to hyperlink text with the variable used as the URL. If you’re not comfortable with code, you can just put the entire URL in the body of the message. The following shows an Outlook step in “Code View.”
First, click “Code View”
Alternative ideas
Calculated column
Note: You could use a calculated column for this, but the [ID] field needed will only populate once, then remove itself on the next property edit. The only way around this is creating another column like ID1 as single line of text and using a workflow (SPD or Power Automate) to set that field to the ID number. Then you can use [ID1] in your calculated column with a formula such as this:
Consider using SharePoint Designer or Power Automate to set a “hyperlink” type field to the URL. This could then be used in a list view to have a one-click link to version history.
I was recently asked to develop a PTO request form that accomplished the following:
Allowed users to submit PTO, Remote work, Training, and Other requests
Auto-lookup of the employee’s manager
Send confirmation to submitter
Notify manager and seek approval/rejection with comments
If approved, send notification with an iCal link users can save to their calendar, and add the PTO to our shared departmental calendar (minus any comments)
Note: This particular build was done on SharePoint Server 2016 and uses a SharePoint Designer workflow.
Create the PTO request form
Thanks to Gregory Zelfond for sharing the idea of using a Tasks web part for this as opposed to a list. Much of this first section is inspired by his post here, with some adjustments for my purposes and preferences.
Add a tasks app and name it PTO Requests
Go to List settings for the new tasks app
Configure Versioning settings as follows
Back under List settings, configure the following Advanced settings as seen here
 Â
Under Views, keep All Tasks, My Tasks, Approve/reject Items, and Calendar. Delete the rest. Rename All Tasks and My Tasks to All Requests and My Requests.
Back under List Settings, under Columns, create the columns shown in green here, and rename those in red. Duration should be the last column you create (number format), and its formula follows the screenshot. Category needs to be the types of “Out of Office” a person could request (like PTO, Remote, Training, Other).
I like the Duration column because it will allow us to show how many weekdays (not including weekends) the PTO Request includes. So those multi-week or broken-week requests show an accurate number for management purposes.
Back under List Settings, select “Task” from under Content Types. Configure each column (hide, make optional or require) as follows:
Click to enlarge
Â
Your new form should resemble this now: Â Â Â
Click to enlarge
Â
You might want to spend some time making your views a nice dashboard as well. Here’s what I did for “All Requests.” Notice I grouped by a different calculated column which determines whether the PTO is Upcoming, Current, or Past and then sub-grouped by category.
Click to enlarge
Create the workflow for approval and calendar addition
In SharePoint Designer, add a new 2010 platform List Workflow for the PTORequests list.
Go to Workflow Settings
Check all “Start Options”
Click “Edit workflow”
Here’s a preview of what we’re going to build:
Click to enlarge
Because this workflow has many steps, I’m only going to show some high-level tips for completing it. Build your workflow to suit your needs. If you have specific questions on how I built mine, please comment.
The approval request email
For the “then Email Current Item: Approver” step, here’s how I did the email:
The link for approving and rejecting is as follows, and you’ll need to replace the red text with a lookup to the current item’s ID. The easiest way to get this might be to do a test submission and copy the link to the approval page where the manager will choose Approved, Rejected, or Pending. You can find this page by viewing a submission, then clicking “Approve/Reject.”
Then just be sure to swap the specific ID with the lookup field for ID.
This will reduce the number of clicks your approvers/managers have to do significantly. Their process will be:
Click big link in email
Select decision and enter comments
Save/Submit
If denied email
No bells and whistles here. You might even include a link to the dash suggesting they submit another request if they wish.
If approved, create calendar item
This is fairly straightforward. If approved, we create an item in a different list. I even edited the “Calendar” view of my PTO requests by adding an “app part” for the separate calendar instead of using the built-in calendar view the task list provides. I then just minimized and hid the chrome of the “Calendar” web part that was already on the view. This allowed me to keep some overlays and other processes related to the second calendar, but see if in context of PTO Requests.
Also, to protect the privacy of those submitting “Other (please explain)” requests (likely FMLA or something private) I have the workflow changing “Other” to just “Out of Office” for the purposes of adding to our shared calendar.
If approved email
Since I created a calendar item if approved, I’m including an iCal link in the approval email for users to open the .ics file and save it to their calendars. Here’s a post on how to structure iCal links. Just instead of creating a calculated column, construct the URL in SharePoint Designer:
Click to enlarge
Improve the look with script (optional)
The following script improves the look of both your views and your forms. It will:
Get rid of “See also” items when viewing requests
Change “New task” to “New request” in your views
Make sure all fields are visible, and not hidden behind “Show More”
Just copy and save the following script as a separate .js file in your Site Assets and follow the instructions beneath the script to add it to your views and forms.
Despite your regional settings being correct, all-day events for some reason are using UTC time when they’re stored and are likely showing as the wrong day in content search web parts and similar web parts.
Though they look correct as an individual item or on a calendar, the way they’re stored doesn’t acknowledge your regional settings and, when pulled through a search web part, render in UTC as beginning 6 (or other) hours earlier than they actually do.
For example, I have a content search web part that pulls all events in our organization and show’s “today’s events.” If there’s an all day event, it shows as starting 6:00 PM the day prior to its actual day.
I could not find a straightforward solution to fix all affected events. And my solution is not ideal, but it accomplishes a need. You could instead explore the possibility of creating a calculated column that adds hours to fix the alignment. But please share if you’ve encountered the same issue and have resolved it a better way.
To get around this issue, I created a SharePoint Designer 2010 Workflow on calendars that:
Triggers on creation or modification
“Unchecks” the All Day Event box
Sets a specific start time on the start date (I chose 7:00AM)
Sets End Time to the original end time (if you don’t do this, it sets end time to blank).
You might run into this issue when running task processes in SharePoint Designer.
“Reason: The user who attempted to complete the task is not the user to whom the task is assigned.”
Assuming the person should actually be able to complete the task, check the following:
Make sure the user who was assigned the task does not have multiple accounts. If they do, the task could have been assigned to the account that the person isn’t currently signed in as when attempting to complete the task.
If it’s someone completing the task on behalf of another, make sure that individual is either:
A Site Owner (site settings, site permissions, people and groups, site owners) or
Task process owner (in SPD 2010 workflows, go to the properties for the task step and set task process owner. Click OK and republish workflow.):
I frequently reference two resources linked at the bottom of this post that speak to the features unique to 2010 and 2013 workflows. Unfortunately, once you pick which workflow platform you’ll be building upon you can’t switch. So it’s important to use these lists in your evaluation phase to make sure you’ll be picking the right platform for the job. Keep in mind, you can always start a 2010 workflow from within a 2013 workflow.
It’s well-known that SharePoint calculated columns don’t permit [Today] to be used as a formula for a calculated date column. And the “default to today’s date” setting only works upon creation, and doesn’t update daily. But we can create a standard date column and have Microsoft Flow automatically update it daily for us, therefore allowing us to effortlessly perform calculations against today’s date such as:
Age =(TodayDate-Birthday)/365
Years of Service =(TodayDate-StartDate)/365
Days Past Due =(TodayDate-DueDate)
Weeks until summer break =(SummerStart-TodayDate)/7
Here’s how to create your own, always accurate/updated, today column (see bottom of post for video):
Automatically create and send reports, files and lists on a regular schedule using Microsoft Flow’s recurrence trigger. Whether hourly, daily, weekly or monthly you can deliver the most current and relevant data from SharePoint or OneDrive to interested parties via email without lifting a finger. Combine this with calculated columns in SharePoint and conditions for some awesome possibilities:
Alerts
Calendar
Relevance
Routine
Report costs or expenditures above a certain amount
Current month’s birthdays and/or workiversaries to your secretary
Send expenses per department or individual to that department or individual
Budget and salary or payroll figures weekly
Notify when an open ticket is idle for a week or incomplete
Upcoming events per location
Share evaluation status with supervisors for just their employees
Recently closed deals and contracts
Survey responses or reviews under 3 stars
Upcoming deadlines per department
Client info and updates to proper salespeople based on location or product
Distribute new hires’ contact/location info to the organization in weekly batches
Microsoft Flow mobile buttons are magical. One touch on your mobile device, and gears start turning to retrieve and deliver the data you need when and how you need it. Recently, I set out to deliver all Microsoft Forms responses to a recipient on-demand as an excel file using a Microsoft Flow mobile button they could press whenever they wanted the results. I also created a button someone could use to be sent all the birthdays coming up in the next week for our organization whenever they need it. You can adjust the following steps to fit your situation and tools, but the following outlines two ideas:
Sending someone all responses to a Microsoft Forms survey whenever they press the button (Take a snapshot in time of responses, or pull up-to-the-minute feedback into your meeting)
Sending someone SharePoint list items in an excel sheet that match a certain criteria (Projects ending in the next two weeks)
