Article published on the 23^rd of November 2020.

Contents

1. Introduction

2. Requirements

3. Configuration

4. Notes

1. Introduction

For a long time, WorkPoint has offered three types of site architectures: Single site collection, multiple entities per site collection, and one site collection per entity.

WorkPoint has now introduced a new architecture type called “Store sites as sub-sites for parent”.

Entity sites created on business modules with this architecture will be created as sub-sites for the business module’s parent module.

This feature can help reduce time needed for data migration from e.g. SharePoint into WorkPoint solutions, as well as simplify permission setups.

An example of the use of this feature could be with a typical Companies – Projects business module setup for Project Management solutions. The Companies business module architecture could be set to one entity per site collection, and the Projects architecture could be set to the new sub-site for parent option.

This would allow all projects within a specific company to be stored in the same site collection.

A benefit of this is that separate site collections for the project module would become unnecessary and permissions at the project site can be inherited from the company site. Furthermore, there will also be certain search benefits as it will become possible to search the company site and all related project sites using standard search scoping features in SharePoint.

The following image illustrates the sub-site concept graphically:

2. Requirements

The sub-site architecture can only be used on business modules whose parent business module utilizes the one entity per site collection architecture.

3. Configuration

Setting a business module to use the sub-site architecture can be done either when creating a new business module or when editing an existing one.

This process is done from the WorkPoint Administration.

In this article, we will go through an example of how to set up a business module which uses the sub-site architecture.

In the following example, we have two business modules: Companies and Contacts. The Companies module utilizes the one entity per site collection architecture and is the parent of the Contacts module. The Contacts modules does not utilize sites at all.

    3.1. Configuration

We wish to create a business module for Projects. A Project is always developed in relation to a company, and as such each project site should be created as a sub-site of a company.

We start by opening the WorkPoint Administration:

1. On the WorkPoint solution, click the “Home” button.

2. In the left side panel, click the cog icon to access the WorkPoint Administration.

3. In the WorkPoint Administration dashboard, under “Business Modules”, click the “Add new”.
   This opens the “Add Business Module” page:

4. Provide a title for the business module. In this case, we title the module “Projects”.
5. Provide an entity name. Typically, this is the singular of the title, so we provide the name “Project”.
6. In this example, we select the “Projects” template for the business module. This populates the module with a predefined set of lists.
7. For “Parent”, we select the “Companies” business module, remembering that we wish project sites to be created as sub-sites of companies.
8. For icon, we select the “Project” icon.
9. Enabling sites allows each project to have an individual site on which documents, e-mails and other items related to the project can be stored. We enable sites for the Projects module.
10. For “Site collection behavior”, we select the “Store sites as sub-sites for parent” option.
11. We also enable automatic site creation. This makes it so that a sites are automatically created for new projects.
12. We click the “Save” button to create the business module using this configuration.

Once the business module creation is complete, the new module should appear in the administration dashboard:

We can now create Project entities from the Projects business module. In this example, we have created three projects, which are associated with one of two different companies:

If we enter one of the project entity sites, we can see in the URL that the project is stored on the respective company site collection:

Note that project entities retain their ID values independent on which company they are associated with. This means that you might have a situation where the first project of a company has an ID of 6.

    3.2. Inheriting permissions

As previously mentioned, one advantage of the sub-sites architecture is that permissions can be inherited from e.g. a company to an underlying project.

Here, we will see a demonstration of this.

13. On one of the companies’ site, we click the “Settings” button.
14. In the Settings side panel, we click “Site permissions”.

15. In the “Permissions” panel, we click “Advanced permissions settings”.

16. In the Permissions page for the company, we can select a permissions group to add users to. In this case, we select to add users to the “Members” group.

17. In the “People and Groups” page for the permission group we selected, we click “New” to add a new user to the group.

18. We add the user “Edward Dean” by typing in his initials and clicking his name when it pops up.
19. We then click the “Share” button.
    Edward Dean has now been added to the Members permission group for the company:

We can now enter the site of a project related to the aforementioned company. In the permissions side panel in the settings menu, we can now see that Edward Dean appears in the “Site members” group for the project:

This works because the project inherits its permission settings from the parent company.

This can also be viewed in the permission settings page for the project:

20. In the yellow warning box, we can see a message letting us know that the site inherits its permissions from its parent, which in this case is the Anderson’s Custom Bikes company.
21. If you wish to break the permission inheritance, you can do so by clicking the “Stop inheriting Permissions” button in the Inheritance ribbon.

It is important to note that permissions can be set by the WorkPoint security system for entities and sites on business modules utilizing the sub-site architecture.

You could e.g. have custom SharePoint groups being used for permissions on a Company. Security rules set for these groups can be used in relation to Project entities related to the company as subsites. Using this setup, it would be possible to make simple changes to personnel in the SharePoint groups, and the security rules would enforce the permissions across the entire company, including the underlying projects.

You can read much more about the WorkPoint security system and how to configure security rules in this article.

4. Notes

There are a set of restrictions associated with the sub-site architecture.

• Only 1 level of sub-sites is supported.
• The master site of a sub-site module needs to be in the same site collection as the parent module site collection.
• It is not be possible to move a sub site entity to another parent.
• Buffer sites are disabled for sub site modules.