You may, at some point, find yourself working with calculations among dates, including “today’s date” which conceptually seems simple but requires a bit of work to function correctly. You may have even created a “today” column that defaults to “current date” or attempted a calculated column only to find that the date will not automatically update each day or that calculated columns cannot show dynamic data like that. Fret no more.
Important: This concept of using calculated columns will only work as a one-time trick. After adding the column, links will be correct. But because [ID] isn’t meant to be used in calculated columns, it removes itself from the formula if an item is edited after the column has been added. This method is only ideal for one-time uses, or for lists that are not expected to have content additions or changes. See this other post about how to get the same hyperlinks through workflow instead, for a more reliable method.
This project allows users a quick option to save something they see on a SharePoint calendar to their own calendar. Spend 5 minutes on these few instructions and your users will have a convenient way to get involved going forward.
Note that in modern calendar experiences, there’s a built-in “add to calendar” option for event items. This post is for classic experience calendars and calendar items/events.
Basically we’re going to add a calculated text column called iCal which will use the list’s GUID (easy to get, don’t worry) and the specific calendar item’s default ID number to generate a clickable .ics (iCal) file link. Let’s get started!
This is a popular request that I’ve recently modified, thanks to the recommendation of a colleague, to be responsive to different device or browser sizes. By default, SharePoint lists respond to their viewer’s size but once customized with a fixed pixel width will lose that feature. This solution utilizes percentages so you can create column widths ideal for any screen.
Update 6/18/19: I’ve recently shared how to adjust widths using CSS and it covers standard AND datasheet views, while the method below is written only for standard views (but could certainly be adapted for datasheet, I imagine).
In a recent post, I discussed hyperlinking URL title text and adding tooltips. I used the above screenshot which also illustrates what we’ll accomplish in this post which is to remove the select/deselect checkmark column, column headers, toolbar edit/new options and chrome border. This leaves us with a simple title and list. Pick and choose what you’d like to remove for your specific needs, and let me know if you run into any issues.
Let’s put those link lists to good use. I wanted one master or parent link list with a number of views. I would then use those views in different list view web parts across my site, removing the toolbar (view/edit/add options), column headers, chrome border and select/deselect checkmark column so that essentially I had a section of my page with a header/chrome title like “HR Forms” (removing default link to “parent” list) and then just a list of hyperlinked form titles with tooltips providing more info on each form as seen above. This post will cover how to get the hyperlinked title text with tooltip. Another post coming soon will cover the “clean-up” of the list view web part so that you’re left with a title and list items alone. Continue reading “Creating hyperlinked titles with tooltips in SharePoint link lists using SharePoint Designer workflow”
Highlighting specific column headers can be useful in drawing attention to specific information areas to make sure they’re complete or just to aid users in seeing the most important info quickly.
You can insert this script in a Script Editor webpart or save it in a css file in your Site Assets and reference the link in a content editor web part on the list page (much more accessible and easy to edit later).
Simply replace “Column1” with the exact name of your column header. Repeat the script as many times as you wish for each column header you want to highlight. Remember to change the script if you change a column name. And if this yellow isn’t your thing, check out this color wheel to help pick a new color code to use in your script.
I recently ran into the following error message in Microsoft Flow that was triggered by a SharePoint – modified list item flow: “The query to field ‘/fieldname/LinkTitleNoMenu’ is not valid.” You’ll see this message in some cases when lookup columns are being utilized on the lists you’re referencing in Microsoft Flow.
This error was caused, at least for me, as a result of setting my “destination” list’s lookup column setting to display as Title (linked to item) instead of just Title. The following details the steps involved in fixing it.
In one of my projects, we built a directory largely based on this article with content created by Stacy Deere-Strole of Focal Point Solutions. Something we ran into was wanting to include multiple departments in our base search query (not refiners, as that only narrows our results instead of expanding them). We also wished to eliminate multiple results in the JobTitle property within the query text. While this is a simple solution, hopefully it will save you some trial and error in writing your search language.
You may have several forms or lists using dropdown menus across your site that you would have to update if, say, an individual resigned, or a department changed its name, or a building relocated. Manage this type of information (individuals, departments, buildings, etc. frequently used in lists and forms) in separate lists that we’ll then use to create site-wide lookup columns to replace the many individual dropdowns across our sites that are repetitious. Basically, we’ll update the information in one place and know that it’s updated everywhere it’s needed across our site (or site collection if you’re familiar enough to go the extra mile with collection content types or Microsoft Flow, if your permissions aren’t at the site collection level).
When working in Office 365 or SharePoint and you open a document for editing, you get two choices. Edit in Word (or Excel) or Edit in Browser. Editing in browser is typically a safe route but it doesn’t give you full functionality like the clients will.
The issue I’m discussing here is when a user tries to edit a document from SharePoint using the client (not Edit in Browser) the client opens to a blank, gray background (no document) or doesn’t open at all. This is likely an account conflict in syncing or accessing.
In other cases, the document may open, but as read-only. If that’s the case, it’s likely permissions-related. You might first check the user’s specific permissions in SharePoint. Sometimes because of broken (not inherited) permissions, or partial access to a site, users are able to edit in browser, but not in the client. If this is your situation, it could well be the cause.
Hopefully this is a simple fix for you, but as it’s become clear to me a number of times with this issue it can be quite complicated. I have a couple fixes, though the second is less ideal. If anyone else has run into this and would like to offer their experience, please do so in the comments.