Best practices for administrating a WorkPoint 365 Environment

Administrating a WorkPoint 365 environment involves a wide range of areas. A few examples are:

• Site collection synchronization after creating new groups
• Updating WorkPoint 365 and Modern UI
• Utilizing Buffer Sites
• Deleting hidden sites after deletion

This article surrounds these areas and more to hopefully help administrating and maintaining WorkPoint environments.

The Buffer Sites feature creates a defined number of temporary sites. The temporary sites are used when new entities are created.

The result of using the Buffer Sites feature is that entity sites get created much faster than without the feature.

A use case for this feature could be if a company regularly creates new projects with associated sites on their solution. They can enable the Buffer Sites feature in order to quickly be able to create projects with sites, which helps quickly start work on a new entity.

More information about configuration of this feature can be found in this article.

The end user will not use this feature directly. End users will simply experience faster creation of sites.

If a site collection has been deleted, the same URL cannot be used when creating a new one. The reason for this is that the deleted site collection URL still figures in WorkPoint's database, which is checked against when creating new site collections. WorkPoint sees that there is a site collection with the same name, and the new site collection will not install correctly.

One solution to this issue is to use a different URL for the new site collection.

Another solution is contacting WorkPoint Support in order to have the URL deleted from the database, so that the URL can again be used for a new site collection.

Updating WorkPoint 365 and Modern UI is done from the WorkPoint 365 Administration.

Updating WorkPoint 365 will update the fields of a solution, should new ones be used by a recently pushed update to the back-end code of WorkPoint. The back-end code of WorkPoint 365 is not updated by clicking the update button in the WorkPoint Administration, and therefore, there is no risk of accidentally update and ruin some part of a solution.

Thus, updates should always be installed whenever possible.

When creating a new group of people on a solution utilizing the Multiple entities per site collection architecture, a site collection synchronization needs to be completed to roll it onto each entity. Site collection synchronization can be executed from the WorkPoint 365 Administration.

The following settings for the Site Collection Synchronization are required for the group members to immediately gain permission to use the solution:

9. Only the "Permissions" option need to be checked as "Yes".
10. All site collections need to be selected. This can be done by clicking "Check all".
11. Click the "Submit Job" button to start the Site Collection Synchronization.
12. The Job list shows all running jobs. If no job is listed, and one should be running, try clicking the "Refresh" button.

This rolls out permissions to the group for all site collections. A scheduled job is set up to do this automatically every 2 hours. Running the Site Collection Synchronization helps grant groups access to the solution immediately. You can read more about scheduled jobs in this article.

Please be aware that this method of granting access works only if the following checkers in Security Settings are checked on:

If you are unsure whether the jobs you are running or have set up to run with the job scheduler, there are a few way you can use to verify this.

One way is to use the WorkPoint Event Log in the WorkPoint Administration. You can read more about using the Event Log in section 7 of this article.

Another way is to use the WorkPoint Web Job Dispatcher settings page in the WorkPoint Administration. This page is used to configure the amount of concurrent jobs from a set of priority categories can run at any given time. More importantly, though, it contains a list of current Web Jobs in queue for execution:

Clicking the "Refresh" button above the list will refresh it to show current information.

The event log in the WorkPoint Administration can be used to track events triggered in and by the system. This can help system administrators to gain insight into many technical core WorkPoint processes.

The Event Log can be accessed from the left side menu in the WorkPoint Administration:

The interface for the Event Log provides a customizable overview of events in the system:

13. The user can toggle which types of events to view in the Event Log. The different types of events are:

• Exception

An error can be surfaced from many different layers of the system, be it SharePoint, WorkPoint, etc. It is logged as an exception in the WorkPoint 365 event log, with a red color.

• Event

Determines the start and completion of a job. These are marked with a green color, when viewing the event log.

• Trace

Traces are informational messages from jobs, showing detailed internal processes that are especially helpful when determining the cause of an eventual exception.

14. The "Job Filter" field can be used to narrow the search to specific types of jobs. This is useful if you know in relation to which job you are searching for event log information. Examples here are "Site creation job" or "Solution update job".
15. The user can specify a time interval for the events shown in the event log. Selecting e.g. "Last 24 hours" makes the event log show all events which were logged during the last 24 hours.
16. The search results fields shows the resulting events depending on the settings from pt. 5-7.
17. The "Load more" button can be used to load more results.

You can read much more about Event Logging in this article.

List throttling refers to when the amount of items in a list reaches a threshold where it hinders the intended functionality of the list. An example could be a business module list of Projects, which starts to reach the threshold of throttling. A way to better maintain the solution and avoid throttling could be to create a new business module which functions as a Project Archive. Closed projects can be moved to this business module, thus removing them fro the main Projects module.

For more general information about throttling in SharePoint Online, please visit this article (external link).

For WorkPoint solutions, there are certain recommendations regarding scaling, e.g. number of subsites per site collection or unique security scopes per list/library. Some of these limitations and recommendations relate directly to the WorkPoint solution while others are in place due to limitations in SharePoint.

The limits set by Microsoft regarding SharePoint Online should always be respected and can be found atSharePoint Online Limits.

You can read more about recommendations and things to keep in mind regarding solution scaling in this article.

When deleting an entity from an entity list, it will still figure in the "Sites marked for deletion" section of the "Site maintenance" page in the WorkPoint Administration.

At this point, the entity and corresponding site can be restored from the recycle bin of the WorkPoint site collection. From the "Site maintenance" page in the WorkPoint Administration, the entity can be deleted for good. This will completely remove the entity and the entity site, and it will not be recoverable after that point. You can read more about this and much more about Site maintenance in this article.

WorkPoint recommends always staying up to date with the latest software. For a guide on how to update WorkPoint Express to the latest version. please visit this article.

The "Site maintenance" page in the WorkPoint Administration is used to clean up sites that are no longer in use. This is relevant in combination with deletion of entities, which is discussed briefly in pt. 10 of this article.

Site maintenance is a job that can be started manually from the Site maintenance page. It can also be set to run on a schedule through the "Scheduled jobs" page. You can read more about scheduling a site maintenance job in this article.

Performing site maintenance may take a while depending on the amount of sites marked for deletion. You can read more about Site maintenance in general in this article.

The App Management page in the WorkPoint Administration can be used to assign the current App to the solution in question. It can also be used to sing up for various APIs and consent to necessary permissions:

In WorkPoint, it is possible to maintain which personnel should be considered primary contact and technical contact for the solution.

These fields are used for getting in contact with people from the solution.

These settings can be found in this way:

18. In the WorkPoint Administration, click "License information" in the left side menu.

This opens the following page:

19. Click the "Edit customer information" button.

20. Use this drop down menu to select the primary contact for the solution. You can choose from the list of contacts also shown in this page.
21. Use this drop down menu to select the technical contact for the solution. You can choose from the list of contacts also shown in this page.
22. If changes are made, click the "Save" button to save the changes.
23. Click the "Create Contact" button to set up a new contact person for use on this page.
24. Click the "Edit" button for a contact to edit that contact. Click the "Delete" button to delete that contact.

When WorkPoint creates columns, we follow certain guidelines:

WorkPoint columns are prefixed with certain letters to indicate column usage or origin. A prefix is a set of characters put in front of the name of the column. WorkPoint uses the following prefixes:

WorkPoint urges partners and administrators who create columns to follow these guidelines in order to comply with the standards for consistent naming.

These prefixes are mostly important for the internal names of columns. Editing column names after creation changes only the displayed name, and not the internal name, of the column. Displayed column names do not need to be prefixed.

WorkPoint urges partners and administrators who create and configure stage gate models not use stage names that are extensive in length.

As a general rule of thumb, try to limit stage names to one or two words, or e.g. 20 characters. Exceptions to these rules of thumb do of course exist.

Using special characters, such as "_", "#", and "/" may present issues in some instances. A general rule of thumb could be simply not to use special characters in naming of columns, entities, or business modules unless necessary.

In case special characters are used for the above mentioned purposes, it is advisable to examine whether features such as mail merge still functions they way it is supposed to.

When creating site columns or list columns, it is generally advisable to provide an internal name without special characters. Editing the name of the column afterwards, special characters can be used, as this will only update the displayed name, and not the internal name, of the column.

It is generally recommended to disable management of content types on the business module lists once created. This will prevent accidents where the content types (stages) of entities are manually changed by altering meta data on the list.