I’m speaking about using Microsoft Flow and SharePoint Designer Workflows to streamline processes this weekend at SharePoint Saturday Kansas City, Sep 16, 2017
“Save” isn’t as familiar/intuitive to non-SharePoint users as language such as “Submit” can be. Change “Save” to “Submit” by adding a script editor or content editor web part (CEWP) to the newform.aspx page for your list.
When writing your own custom headers and footers, you probably don’t want/need that script showing in modal dialog windows too. It can look sloppy or accidental and may wrap oddly, as seen in my example above.
Luckily, it’s an easy fix.
We’ve all been there. One location on a shared calendar will be referred to by multiple people as 20 different things. Johnson Building Room 214 can be entered as “214,” “Johnson 214,” or “J214” to name a few. Canceled events stay on the calendar, sucking up real estate and waiting for someone to delete it manually. Items copied from another calendar make you pay for the convenience of a simple copy and paste by adding the “Copy: ” prefix to the item.
But with a single workflow, we can fix all of these and make our SharePoint calendars look more professional and polished without making more work for end users. This post will cover how we can use workflow to standardize naming of locations with workflow, delete events once they’ve been canceled and get rid of Outlook’s “Copy: ” prefix. You will need SharePoint Designer and appropriate permissions to create workflows to complete the following steps:
SharePoint Designer 2013 workflows verify workflow email recipients are part of your organization, while SPD 2010 workflows do not.
Yes, you can have a BCC field in your SharePoint Designer workflow emails. I didn’t know this until recently, and was pleasantly surprised. It’s quick and simple, so let’s get started.
Note: You can do this in both 2010 and 2013 SharePoint Designer workflows, using the exact same steps.
One of the greatest business value features of a site newsfeed webpart would obviously be to know when people are participating, asking questions, etc. This way moderators or other interested parties could go in and respond in a timely manner. And while there’s no straightforward way to get these notifications from the webpart itself, there’s a workaround. Follow these steps once you have a newsfeed webpart on your site (by default, most team sites have them already).
Note: This, like many O365 things, is rapidly evolving. If you’re aware of better practices or new updates to licensing, feel free to mention it in comments.
I’m currently at SharePoint Fest Seattle where Chris McNulty, Sr. Product Manager for Office 365 and SharePoint at Microsoft, mentioned (as I understand) there could be changes coming to licensing that would allow more people to consume Power BI reports in a friendlier (more affordable) licensing structure. This would be amazing because currently:
I can create reports. People can’t view data in those reports in a secure way because the entire organization isn’t licensed for Power BI per person above the “free” license.
Specifically I, with a Power BI Pro license, can create reports and place those in SharePoint’s new page experience Power BI web parts (in Preview) but other people (with free or without Pro licenses) cannot view them. They see the following:
Of course, to me as the creator and properly-licensed individual, I see the report perfectly embedded as it should be. And not every organization can afford to license every single user appropriately to be able to simply view embedded reports. Especially if consuming reports (not sharing or building) is the only function they need in the Power BI realm.
In this post, I’ll cover:
- How to embed Power BI reports the normal, easy (but license-exclusive) way
- Why the webpart (normal, easy way) is cooler than embedding a script
- How to embed the report in a (less secure) way so that non-licensed or free-license individuals can actually view and manipulate the data
If you’ve found this post by search, you’ve likely already gone into the workflow settings for a particular list or document library item and have clicked the info icon () next to “Internal status” and found that your workflow is “in progress”, but has an error: “Access Denied. You do not have permission to perform this action or access this resource.” Peering into the bulk of the message, you see a helpful tidbit that includes sp.utilities.utility.SendEmail. This could be from a number of causes, but here are the summaries of three possible solutions. Note that the first solution is still required even if you try B or C below. I’ve only included the second and third solutions as additional possibilities if the first doesn’t solve your problem.
A common question, before we begin, is what level of permissions any individual needs to be able to send an email or start a workflow generally. It doesn’t matter so much if you’re using Impersonation or App Steps, but the quick answer is a minimum of Contribute level permissions is good.
Sometimes you’ll into situations where a SharePoint Designer (SPD) 2010 workflow is the only way to go in order to make something work. In May 2017, I gave a presentation at SharePoint Saturday Baltimore and shared the following slide of functions only possible by using a SharePoint Designer 2010 format workflow.
Unfortunately, you may have loads of conditions and stages already built in a SPD 2013 workflow by the time you realize you need some of this 2010-exclusive functionality. No need to fret, however, because we can start that necessary 2010 workflow from wherever we need to within our 2013 workflow, as if it were just another ordinary step.