1. Custom Theme:
Clients commonly ask for help in applying a custom theme to their SharePoint intranet. This typically includes choosing the colors for the top bar, choosing a logo to display, making sure fonts and colors match company fonts and colors, and setting a background image.
The thing to remember about applying a custom theme is that there is a right way and a wrong way to do it. For years now, we’ve been dissuading folks from using custom master pages to apply themes. Customizing master pages leads to issues with upgrading and migrating in the future. Instead, we suggest using the built-in tools SharePoint provides to customize the theme.
This is a little tricky, and we recommend leaving it to a professional. You have to customize a font and color file using a special tool, and then deploy the theme across the tenant. There is not an easy way to do this through the SharePoint UI, so we typically use a script we’ve written for this purpose.
2. Surfacing List/Library Data with Custom Widgets:
This comes up all the time when building out an intranet home page. A good example would be a customer requesting a widget on the home page that shows the title of the latest company newsletter along with an image from that newsletter, and when a user clicks on the image the file opens.
We tend to use calls to SharePoint’s REST endpoints to get this done. Using this type of customization, we can quickly build out widgets that will display any data you have stored in lists or libraries in any way you choose.
Other examples of this type of customization we’ve implemented in the past include widgets for employee of the month, safety statistics, messages from an executive, upcoming company events, press releases, rig counts, and more.
3. Custom Search Display Templates:
We often build unique search experiences that solve specific business problems. An example would be a construction company storing Standard Operating Procedures (SOPs). Having the documents stored and tagged correctly makes finding them simple, but the experience gets even better when you have an SOP search result source that’s right there in the search box, leading to a search results page that can surface each SOP’s information in exactly the way you want, plus refiners tied to the SOP’s metadata.
A more advanced customization that we’ve implemented in the past for an upstream oil and gas company involved well files being tagged with a location. When a user searched for a well file, they would get the list of results. When they hovered over one, the preview screen that popped up included a map showing the location of the well.
4. Form Customization Using JSLink:
SharePoint 2013 introduced a new way to control how forms display data by allowing developers to specify a link to a “JSLink” file, a JavaScript file that modifies the form template. Using this approach, we can completely change how the form displays, or how specific fields are rendered.
This approach can be used to build custom status indicators. Imagine that you had a list of projects, and a column indicating whether they were behind, on-track, or ahead of schedule. Using a JSLink file, we could change that column to display a red, yellow, or green icon so that users could tell at a glance how each project was doing.
Another common use case is changing the way tasks display. Normally, tasks show many different columns, and an annoying “Show More” button, meaning several fields are hidden by default. We have developed a JSLink file that changes the way this default template behaves. It shows all fields by default, it hides fields that people usually don’t care about, such a predecessor, and it hoists Title and Description to the top of the form to serve as an introduction and explanation for completing the task. We think this is a much more appropriate place to have them than buried in the form with all the other fields.
The best part about this approach is that it is portable (the JSLink file can be copied to other locations), safe (if there is an issue with the file SharePoint just ignores it and goes with the standard template), and supported (this is a sanctioned approach to extensibility).
5. Integration with External Systems:
This is a common customization with too many variations in approach to cover here. In on-prem versions of SharePoint, when talking to other systems on the network, setting up external columns and content types is the way to go. Many systems have connectors with SharePoint or apps/web parts that surface functionality through the SharePoint UI. If the system has REST endpoints, our team can typically pull or push data from SharePoint without too much trouble. Even systems with non-standard APIs can be integrated given some time, although the approach would change and would be more complex.
The upshot of all of this is that our team can typically make something work. Our clients turn to this type of customizations when they want to use SharePoint as a hub, connecting systems and allowing their users to work in one place, rather than multiple.
Clients typically engage us during the planning phase to help with the architecture. We help people build a business case for integration with other systems, specify what users are trying to do, and then plan the best way to build out the integration. Depending on the technical savvy of the client, we will either execute the integration project or serve as resources when needed while they do the actual coding.