WorkPoint 365 Security - Best Practices

This article explains how to configure security in WorkPoint 365 using a practical best-practice model. The goal is to help solution architects and administrators design security in a way that is simple to manage, performs well over time, and scales across many sites and entities.

The recommended approach is based on a clear division of responsibility between SharePoint and WorkPoint 365. SharePoint groups should be used as the main permission layer, while WorkPoint 365 should primarily be used to place the right users into those groups based on metadata. This reduces complexity, limits the amount of security processing required when data changes, and creates a more predictable and maintainable security model.

In practice, the best model is to move through security configuration in the following sequence:

1. Define a simple role model
2. Create the SharePoint groups that represent those roles (e.g., Project Manager, Team, etc.)
3. Make those groups available where needed
4. Use dynamic security rules to populate the groups
5. Use static security rules to assign permissions to sites, libraries, and lists

When these steps are followed in order, security becomes easier to govern and easier to maintain

The first step is to decide which business roles need access and keep that model as simple as possible. In most project-based WorkPoint 365 solutions, a small number of clearly defined roles is enough. A typical example is:

• Project Manager
• Team
• optionally, roles such as Executive, Stakeholder, or External Contributor

This is important because security models become harder to manage when too many roles are introduced. A small and stable role model makes permissions easier to understand, reduces administrative overhead, and lowers the risk of inconsistent access across the solution. The original article explicitly recommends keeping roles simple and avoiding unnecessary complexity.

Once the roles are defined, create matching SharePoint groups. These groups should become the foundation of the security model.

For example, in a Projects solution, create:

• Project Manager
• Project Team

These groups should be created at the root site level so they can serve as the common security structure for the rest of the solution. The key principle here is that permissions should be assigned to groups, not directly to individual users. This keeps security administration cleaner and reduces the likelihood of fragmented permissions and broken inheritance.

After creating the SharePoint groups, the next step is to ensure they are available wherever they are needed. For example, if you have created SharePoint groups related to projects, e.g., Project Manager and Team, those should be available on Projects, not necessarily on other types of work items.

First, synchronize the groups to the master site collection of the relevant module using Site Collection Synchronization. Then use Security Replication so the same groups are available on all project or entity sites.

This step matters because it creates a consistent security structure across the entire solution. Instead of building permissions differently from site to site, you establish a standard group model once and push it throughout the solution. That consistency improves governance and makes future administration much easier.

When the group structure is in place, configure dynamic security rules to manage group membership. This is where WorkPoint 365 should do its main security-related work.

For a Projects module, the typical setup is:

• A dynamic rule that reads the Project Manager field and adds that user to the Project Manager SharePoint group
• A dynamic rule that reads the Team field and adds those users to the Project Team SharePoint group

This is the preferred use of dynamic security because it keeps the logic lightweight. When project ownership or team membership changes, administrators only need to update the metadata fields. WorkPoint 365 then updates the relevant group membership automatically. No one has to manually edit group members, and no permissions need to be reassigned across content.

Once users are being placed into the correct SharePoint groups, the next step is to assign actual permissions to those groups. This should be done with static security rules.

In other words, dynamic rules decide who belongs to a role, and static rules decide what that role can access.

The article’s example permissions model gives the Project Manager broader rights and the Project Team more limited contribution rights. The table on page 5 shows this pattern:

• Project site: Project Manager = Full Control, Project Team = Edit
• Documents library: Project Manager = Full Control, Project Team = Contribute
• Tasks list: Project Manager = Full Control, Project Team = Contribute
• Risks list: Project Manager = Full Control, Project Team = Contribute

This approach is important because it separates membership management from permission assignment. Once the static permissions are in place, a role change does not require WorkPoint 365 to reapply permissions across every library, list, or item. It only needs to update the user’s group membership. That is a much lighter operation and is one of the main reasons this model is considered best practice.

A key best-practice point is to avoid using dynamic rules to assign permissions directly to libraries, lists, or items whenever possible.

The reason is performance and operational load. If dynamic rules are used directly on content, WorkPoint 365 may need to process many objects every time a metadata value changes. In larger environments, that creates unnecessary overhead and can lead to slower updates and more complex security behavior. The article explains that the only heavy operation you want during role changes is group membership updating, not broad permission reassignment across content.

This is why the recommended model is:

• dynamic rules for users into groups
• static rules for groups onto content

That division keeps the security setup predictable and efficient.

Consider the following diagram:

In this diagram, we have two groups on the root site collection; Project Manager, and Project Team. These are synchronized to the Projects module's Master site collection using Site Collection synchronization. From there, they are synchronized to Project entity site collections using Security Replication. Now we have the Project Manager and Project Team SharePoint groups on each Project site collection.

On the Projects module, there are two important metadata columns; Project Manager, and Team. Using WorkPoint Security, we create Dynamic security rules to assign the person in the Project Manager column to the Project Manager group, and the people in the Team column to the Project Team group.

Next, we use WorkPoint Security to create Static security rules which grant the members of the Project Manager group Full Control permissions to the entity site lists, and the members of the Project Team group Contribute permissions to the same lists.

Since the rules which actually grant permissions to the entity site lists are static, and only the memberships change, whenever changes are made to a project's role-columns are made, WorkPoint only needs to update the group memberships - not the permissions on each list, library, or content.

✔  Use SharePoint groups for all security assignments

✔  Use dynamic rules only to populate groups

✔  Use static rules for lists, libraries, and site permissions

✔  Synchronize all groups to master and replicate to entity sites

✔  Avoid content‑level dynamic rules

✔  Keep security role models simple