Remove claims token with regular expressions and Nintex on Office 365

Remove claims token with regular expressions and Nintex on Office 365

When you get the value of a person via Nintex Workflows, you often get a bit of a messy string back – it starts with “i:0#.f|” and may also be “i:0#.f|membership|” . That string is the claims token. Here’s how to get rid of it using the Regular Expression action on Office 365.

Continue reading

Add an extra group for management to a team site

SharePoint permission configuration is one of the hardest things for end-users to understand. Sometimes it is easier to explain a specific scenario instead of how the entire permissions concept works.

This article will explain the following scenario:

  • The DW&C team has a new team site
  • Visitors should have read access to the site
  • People in the DW&C should have contribute permissions
  • There should be a group of site admins for taking care of the site
  • There needs to be a separate document library that only the management team has access to

This scenario would work in exactly the same way if this was a project site.

To start off, we’ll assume that the DW&C department has already created a standard team site.


Standard team site permissions

Our scenario team site has now been updated to have an extra Management Documents library and a calendar.


When creating this site, we created new permissions, which means that SharePoint automatically created the following groups with the following permissions:

Group Permission level Users Explanation
DW&C Site Visitors Read All users On an intranet, it’s best to give as much read access as possible to ensure transparency and findability.
DW&C  Site Members Contribute All DW&C users All users in the department should have the ability to influence the information on their department site.
DW&C Site Owners Full control Owners/admins Choose a few users to manage the site, i.e. super users.

Note: some people suggest adding the department’s manager to the Owners group – after all, they are responsible for the department. However, managers should generally be added to the Members group. Specific users should be chosen to manage the site and be added to the Owners group. The managers will get extra access to their specific documents later in this scenario.

In the starting scenario, the users in these groups have access to all of the content on this team site as nothing specific has been configured.

SharePoint objects, i.e. sites, lists, libraries, folders and items, inherit permission from their parent item.

This means that all users also have access to that Management Documents library, which should be kept separate just for DW&C’s management team.  To configure that, we will need to set up a new user group.

Creating a new user group and filling it

In SharePoint, it is possible to assign permissions in three ways:

  1. To a SharePoint group (add Active Directory users, groups or SharePoint groups)
  2. Directly to an Active Directory group
  3. To an Active Directory user

The first two options are fine, in most cases. However, option #3 should generally be avoided. It is much better to create a group and assign permissions to the group rather than assign permissions directly to a user. The contents of the group is far easier to maintain rather than going through and changing a specific user’s permissions.

It is possible to directly assign permissions to AD groups, which does have advantages in some environments. However, when working with an intranet team or project site, SharePoint groups are usually the easiest to work with.

To create a new group for a site, do the following:

  1. Go to the site you wish to add the group to
  2. Click the cog wheel and go to “Site Actions”
  3. Choose “Site permissions”
  4. Choose “Create group” from the ribbon




Note: the new user group will be available for the entire site collection, not just this one site. You should name it accordingly – in this scenario, I will name it “DW&C Site Management” to keep with the current naming convention.

When creating the group, the current user is set as owner. In most cases, this should be set to the site owners group, so that they can maintain the membership of this group.


I suggest giving this group “contribute” permissions.


Once the group has been created, you can add users to the group by clicking “New” and “Add users”. You should be able to select the applicable management users from the Active Directory by typing in their names, emails or user IDs.

For more information on adding users to a group, please see Manage SharePoint groups.

Changing the permissions for the Management group

Now we have the DW&C Site Management user group, but we need to change the permissions on the Management Documents library so that only the Management user group has access to it. To do that, we will need to break the permission inheritance on the Management Documents library.


To change the permissions on the Management Documents library, please do the following:

  1. Go to the library
  2. Go to the “Library” tab and choose “Library settings”
  3. Choose “Permissions for this document library”
  4. Observe that the library currently inherits permissions from its parent, the DW&C Site. Click “Stop inheriting permissions” to break the inheritance.
  5. Now the library has unique permissions; the options in the ribbon have changed.  If you want to revert back to inheriting permissions, you could click “Delete unique permissions”.
  6. Remove the visitor and member permissions by selecting the groups and choosing “Remove user permissions” in the menu. As of now, the users in these groups will not have any access to the Management Documents library.

As a final step, you should determine if the DW&C Site Owners group should retain their permissions. Note that one group will need to have “full control”, so either the Owners group will need to stay or the Management group will need to have their permissions upgraded.


Technet: User permissions and permission levels in SharePoint 2013
Technet: User permissions and permission levels in SharePoint 2010
Office support: Manage SharePoint groups
Technet: Best practices for using fine-grained permissions in SharePoint Server 2013

Calculated column: week number

I decided to organise a small project by using a SharePoint task list on a Office 365 project site. I figure that if it gets too complicated, I can always just open the entire thing in Microsoft Project.

I realized fairly quickly that seeing week numbers in the list was a valuable thing:

  • Group the tasks by week
  • See the total number of estimated hours per week

I created a calculated column and used the comments on this page, Group A List by Week Number. I ended up changing the formula a little bit – there are some activities in December and some in January, so I wanted to see the year, as well as the week number for sorting purposes.

My final formula:

=YEAR([Start Date])&"-"&If(Int(([Start Date]-Date(Year([Start Date]);1;1)+(TEXT(Weekday(Date(Year([Start Date]);1;1)-1);"d")))/7)=0;52;Int(([Start Date]-Date(Year([Start Date]);1;1)+(TEXT(Weekday(Date(Year([Start Date]);1;1)-1);"d")))/7))

The final result looks like this:


You can see an error on the third line: that’s because [Start Date] is empty on that line, so the week number could not be correctly calculated. I just wanted to get on with the project planning and not spend more time on the formula.

Once you have the week number in place, you can easily make views like this one, where I grouped by Week and then summed up the total hour estimate:


The formula has the following considerations:

  • Weeks begin on Monday
  • Working with Swedish regional settings – you may need to change around a few periods, semi-c0lons, etc.