Thursday, 7 December 2017

Nintex Workflow for O365 - Get Manager Email Address

Nintex Workflow in Office 365 is different from On-Premise, so here's how you can grab a manager's email address.

If you want to assign a task or email the manager of the person who submitted an item.

Click in the Text Box you would like to add the email address to and using the right-hand navigation menu select Workflow Context > Manager Email Address


Office 365 - How to Link Directly To A Users Delve Profile With Email Address

You've probably seen it before, when you navigate to a persons Delve profile in Office 365, the URL contains a unique UserID.


Well there is a way to create a link that will send you to a users Delve profile based on their email address

You may want to programatically show a list of users and link to their Delve Profiles.

The link below allows you to input an email address at the end, Office 365 will automatically translate this and re-direct you to the Users Profile


Monday, 13 November 2017

PowerApps - Default SharePoint People Picker Field To Be Logged In User

When you're building a PowerApp connected to a SharePoint List Form and you would like to capture the details of the person who is filling out the form.

I understand that this is already captured via the 'Created By' SharePoint System field, but sometimes customers like to capture requestor name, phone, etc on the form itself rather than having to go to SharePoint to view it all.

  • You've already created a PowerApp and added a 'Form' Control that uses a SharePoint List as a Data Source.
  • Your SharePoint List contains a People Picker Field
  • To pull back details about users, add another Data Source: View  Tab > Data Sources > Add Data Source > Office 365 Users
  • Click on the Card in the form that contains your People Picker Field
  • Go To Advanced and click 'Unlock to change properties' so that you can select the field itself
  • Click on the People Picker Field itself, then select the 'Default' function and type Office365Users.MyProfile()

Now when you open up the PowerApp it should automatically populate the People Picker field with the user who is logged in.

You can use the same concept to auto-populate other fields inside your form with specific user details.  For more info check out this Microsoft article explaining the Office 365 User Data Source:

Friday, 6 October 2017

Deleting an Office 365 Group Deletes your Yammer Group

Even if the Yammer Group was created first... So yeah, don't delete O365 Groups unless you want everything gone.

If you need to recover:

##Do this off Network with regular powershell opened as Administrator

Import-Module AzureADPreview


Get-AzureADMSDeletedGroup | Out-GridView

Restore-AzureADMSDeletedDirectoryObject –Id xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Get-AzureADGroup –ObjectId xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Update - 08/12/2017
Microsoft are rolling this restore functionality into Exchange Online over the next month or two, so you wont need the script above soon:

Friday, 1 September 2017

SharePoint Online - Share or Copy Link Button Defaulting to 'GuestAccess' Link

Ever tried to copy or share a link in SharePoint Online and it defaults to providing you with a Guest Link that is 'accessible to anyone in the organization'?

It's a really good option for staff that want to quickly share a document without having to understand SharePoint Permissions.

Unfortunately, the Guest Access Link forces the user to open up the document In-Browser using Office Online.  I personally can't abide this until the functionality between Online & Client are 1-to-1.

How to Fix
SharePoint Online defaults the Sharing settings for copying & sharing links to "Internal - People in the Organization Only' , which basically means 'Guest Link that opens in browser'.

To change this you just need to go to:

  • SharePoint Administration Center
  • Sharing Tab
  • Change the 'Default Link Type' setting from 'Internal' to 'Direct - Only people who have permission'
  • Done!  No more links with 'guestaccess.aspx' in them.

Thursday, 27 July 2017

SharePoint Online - Hide External Users from Global Search Results

Had a problem where external users (people outside our organisation who had been provided with an anonymous link to OneDrive/SharePoint Documents) were showing up in SharePoint's People Search Results.

This article explains how to fix:

Basically you need to add a Query Rule to SharePoint's 'Local People Results' Search Query to block out results that contain the external users.

I personally filtered out all results where a persons Username contained '#EXT#', which is what gets appended in Office 365 whenever an external user is given access to a document.

Friday, 9 June 2017

SharePoint Online - Automate Site & Group Creation with Nintex Workflow O365

Nintex Workflow for O365 has an action to create a site automatically in SharePoint, but it's functionality is quite limited.  You can't create groups and you can't add staff to those groups.  This tutorial shows you how to create a Nintex workflow to automate the whole process using SharePoint Web Services.

Even better, we are going to create the ability to automate Site Creation across multiple Site Collections.

If you're looking for a tutorial on how to do this in Nintex Workflow 2010/2013, I've written an article here: SharePoint 2010 - Automate Site & Group Creation with Nintex Workflow 2010

As most SharePoint administrators are aware, it's ALWAYS a bad idea to give staff the ability to create SharePoint sites.  They will end up creating them for the wrong purposes, will not maintain them, no retention policies will get assigned to them, etc.

However, you don't want to restrict your users creative freedom.  You want to govern it in a manageable way.

In order to keep track of all your SharePoint sites, we need to ensure that when we allow staff to create sites/content, it is being properly tagged with the right information.  As long as you are logging & tagging sites with extra data, you can easily govern and manage those sites far into the future.

This tutorial isn't simply how to automate a process that SharePoint already does.  It's automating that process while enforcing that users to tag their sites with data that will help you manage SharePoint easier.

We are going to use the example of Project Sites.  Project sites have a known lifespan, usually between 1 month & 2 years depending on size.  We want to capture that information so the sites don't hang around for too long.

There are 6 steps in my workflow, they are:
  • 1. Set Variables
  • 2. Create Site
  • 3. Create Group
  • 4. Add Group to Site
  • 5. Add Members to Group
  • 6. Send Emails

First:  Create a custom list with the following columns (depending on your needs):
  • Project Name
  • Site Description
  • Site URL
  • Site Owner
  • Site Type:  Project / Team
  • Department
  • Project Sponsor
  • Project Manager
  • Project #
  • Estimated Completion Date

1. Set Variables
I created & set the following variables so that the Web Services would run with the correct information:
Site Collection URL - used if you are planning to allow this workflow to create sites on multiple site collections
Site Template - If you want different site templates to be used on different types of sites
setting variables based on 'Site Type' (using Switch Action and Set Variable Actions)

2. Create Site
Use the following Nintex Action to create a site and add all the data you will collect from your list: Office 365 Create Site
Create Site Settings

3. Create Group
Use the following Action to query a Web Service:  Web Request

If you're wondering how I figured out what to input, this guide explains how to get SOAP Web Service Information perfectly:

Insert these values to create an 'Owners' Group on your Site Collection without access to anything:
  • URL: ‍{Variable:Site Collection URL}‍_vti_bin/UserGroup.asmx
  • Method: SOAP 1.1
  • Soap Action:
  • Body: Content

<?xml version="1.0" encoding="utf-8"?> 
<soap:Envelope xmlns:xsi="" xmlns:xsd="" xmlns:soap="">   
<AddGroup xmlns="">       <groupName>‍{Current Item:Site Name}‍ Owners</groupName>       
<ownerIdentifier>‍{Current Item:Site Owner}‍</ownerIdentifier>    
<defaultUserLoginName>‍{Current Item:Site Owner}‍</defaultUserLoginName>       
<description>Used to manage permissions on this site: ‍{Variable:Site Collection URL}‍‍{Current Item:Site URL}‍</description>     

4. Add Group to Site
the hard part...

Now we need to give the group access to your newly created site.  Create another Web Request Action.

The picture will explain most things, however, to get the PermissionMask value (a value assigned to a permission level like Contribute,Read Only, etc), you need to run the following Powershell script on your server: SharePoint Online - Retrieve the Permission Mask Values for a Site using Powershell

FYI: For Owner access with Full Control, the permissionMask is always -1.

Once you have that, Insert these values
  • URL: ‍‍{Variable:Site Collection URL}‍‍{Current Item:Site URL}‍/_vti_bin/permissions.asmx
  • Method: SOAP 1.1
  • Soap Action:
  • Body: Content
Body: <?xml version="1.0" encoding="utf-8"?> 
<soap:Envelope xmlns:xsi="" xmlns:xsd="" xmlns:soap="">   
<AddPermission xmlns="">       
<objectName>‍{Current Item:Site Name}‍</objectName>       
<permissionIdentifier>‍{Current Item:Site Name}‍ Owners</permissionIdentifier>       

Running the AddPermission Web Method through the Permissions.asmx web service

5. Add Members to Group
You don't need to do this, but if you're feeling keen you can also run a web service to add a user to the newly created group.  Same setup as Step 4, just use the following settings:
  • URL: ‍‍{Variable:Site Collection URL}‍‍{Current Item:Site URL}‍/_vti_bin/UserGroup.asmx
  • Method: SOAP 1.1
  • Soap Action:
  • Body: Content
<?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="" xmlns:xsd="" xmlns:soap="">   
<AddUserToGroup xmlns="">       
<groupName>‍{Current Item:Site Name}‍ Owners</groupName>       
<userLoginName>‍{Current Item:Project Manager}‍</userLoginName>       

6. Send Emails
Of course now you want to send a nice customised email to your user with all the information they need!

This saves our team so much time, while allowing us to govern site creation and ensure that all sites have metadata tagged against them !

Have you got any cool tricks to help automate governance that you'd like to share?

If you liked this post:
Credit where it's due

Thursday, 8 June 2017

SharePoint Online - Retrieve the Permission Mask Values for a Site using Powershell

This article stems from another article explaining how to [[Automate Site & Group Creation with Nintex Workflow O365]] - Coming Soon

Use Powershell to retrieve detailed data about the permission levels on a particular site

I had previously created a Nintex Workflow to Automate Site & Group creation using nintex workflow on SharePoint 2010.  I needed to recreate the same workflow in SharePoint Online / Nintex Workflow O365, however the SharePoint 2010 script for retrieving Permission Mask values did not work.

Using Powershell 3.0 or later, and SharePoint Online Powershell Module.  Open up the SharePoint Online Powershell Module and paste the following code (after updating the variables at the top for your site and admin details):

# SharePoint Online - Retrieve the Permission Mask Values for a Site using Powershell

# Specifies variable
$AdminURI = ""
$LogFile = "C:\Temp\GetSitePermissions.xml"

# Specifies the User account for an Office 365 global admin in your organization
$AdminAccount = ""
$AdminPass = ""

# Begin the process
$loadInfo1 = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client")
$loadInfo2 = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.Runtime")
$loadInfo3 = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.UserProfiles")

# Convert the Password to a secure string, then zero out the cleartext version ;)
$sstr = ConvertTo-SecureString -string $AdminPass -AsPlainText -Force
$AdminPass = ""

# Take the AdminAccount and the AdminAccount password, and create a credential
$creds = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($AdminAccount, $sstr)

# Add the path of the User Profile Service to the SPO admin URL, then create a new webservice proxy to access it====================================================
$proxyaddr = $TargetSiteCollection+ "/_vti_bin/Permissions.asmx?wsdl"
$UserProfileService= New-WebServiceProxy -Uri $proxyaddr -UseDefaultCredential False
$UserProfileService.Credentials = $creds

# Set variables for authentication cookies
$strAuthCookie = $creds.GetAuthenticationCookie($RootSiteCollection)
$uri = New-Object System.Uri($RootSiteCollection)
$container = New-Object System.Net.CookieContainer
$container.SetCookies($uri, $strAuthCookie)
$UserProfileService.CookieContainer = $container


Write-Host "Starting- This could take a while."
$output = New-Object -TypeName System.IO.StreamWriter -ArgumentList $LogFile, $false
$output.WriteLine("<?xml version=""1.0"" encoding=""utf-8"" ?>")
Write-Host "Done!"

Thank you to the Microsoft Support team that assisted in the process of building this script!