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.
There are three possible causes I’m aware of that you should check if you receive this message:
Central admin settings not configured properly
Site collection settings not configured properly
You’re using a Project Web App (PWA) site template and can only fix this on SharePoint Server
I’ll cover the solutions for each in the same order:
Go to central admin –> manage web applications
Select the web app on which you received the error and select “SharePoint Designer” from the general settings drop-down. Make sure the first box is checked and click “OK.”
Site collection settings
Go to site settings –> SharePoint Designer Settings (under Site Collection Administration)
Make sure “Enable SharePoint Designer” is checked and click OK
Project web app template issue
Log in to a SharePoint server and go to C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\SiteTemplates\PWA\XML
Open the ONET XML file in a text editor like NotePad
Search for “webdesign” (Ctrl+F to open search) and delete the following property:
Perform an IIS reset (run SharePoint management shell as administrator)
You may need to repeat these steps on multiple servers if you have multiple web front end servers. You can just copy the ONET file and overwrite the same file on the other servers in the same location. Don’t forget to do an IIS reset afterward on each.
Close and re-open your Project Web App site in SharePoint Designer and you should now be able to edit as you do with other sites.
On one of my recent projects, a client asked if it would be possible for the link to a task within a workflow notification email to open the task in “edit” mode instead of “display”. If you’re unfamiliar with SharePoint 2013 task processes built in SharePoint Designer, here’s what their process looked like prior to our change:
Someone submits form
Approval request sent to manager
Manager clicks link in email to open task
Manager clicks “Edit”
Manager clicks “Approve”
They wanted to eliminate step 4 to make the process as easy as possible (one-click after opening link in email). Here’s what we ended up doing:
I recently developed the above solution for a project requiring attachments at multiple points throughout the form. Originally I considered just placing a static “attachment button” in multiple places, but I came up with this and liked it better.
So if you also have long forms for your SharePoint lists, and you would like an easier way for end users to add attachments to list items, ditch the out-of-the-box ribbon menu attachment button and try this “floating attachment box” solution instead.
When you create a custom new item form in SharePoint Designer, you get a bonus set of “Save” and “Cancel” buttons automatically generated. One set at the top, and one set at the bottom (as generally seen on default forms).
Chances are if you’ve created a custom new item form, you had other intentions for the space now taken by duplicate buttons. Here’s how to get rid of the spare buttons and get back to designing and tweaking your custom new item form.
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.
Perhaps one of the most useful automated processes out there is the ability to do approval processes. We fortunately have two tools on-prem or online that allows us to perform this action. Microsoft Flow offers some incredible connectivity between services (like approve a Tweet and post it, approve something from Google Docs and have it moved to SharePoint, etc.), but the approval process itself is very simple at this point and doesn’t offer some of the more robust features and customization options we get in SharePoint Designer 2013 approval processes.
I also will use both tools in the same business process occasionally, because they both have unique strengths.
But which do you use for approvals?
The quick answer to the question is: Use Flow for simple approvals, or approvals that involve multiple sites or external services. Use SPD for more complicated processes and customization options for approvals that involve a single site.
Below on the left are two traditional, out-of-the-box solutions for showing Today’s events in SharePoint. Notice how both take up a lot of extra space repeating today’s date (which we don’t need to see at all in a web part called “Today’s Events”) or showing gray space where there are no events. Soak that in – prime real estate on your home page goes to non-existent events. These also may require overlays and other manual labor processes that need adjusted every time a calendar is added or removed.
But on the right is what you could have. It uses search instead and displays events from all calendars a user has access to in one place. It shows only the necessary information on the home page and links to full details. And with a little CSS included in this post, it can look polished and themed. Imagine all you could do with that saved space on your home page…
Perhaps you, like me, built an exciting Microsoft Flow workflow and let it go into the wild without much additional thought. But at some point, you drop a lookup column into the mix and your Flow stops working. It tells you the field is not supported in query, even if that specific field isn’t being utilized in the Flow. I believe this has something to do with REST, but we won’t dwell on the cause – let’s get to the workaround.
The scenario I’ll be using is my cross-site publishing alternative using Microsoft Flow where I’m basically copying data from list items in one site collection to create new list items in a different site collection. This is helpful when someone does some sort of data entry once, and other people are then entering much of the exact same data. This copies all of the overlapping data to a new list item for the second site collection to reduce duplication of work.
It sounds simple but with a lookup column in the destination list we get the error. For this I’ll be using SharePoint Designer and Microsoft Flow (of course) in combination, though you could certainly try it all in Microsoft Flow. I just find parts of the process simpler in SPD. And while your origin data may be different (MailChimp, Twitter, etc.), and your exact scenario may differ, this workaround should still have value in concept.