To show the document URL and not the durable link in the document preview callout on SharePoint Online, you can include the following JavaScript in your page (or in a master page, user custom action, etc.)
You can find the source code on Gist.
I wrote this script as a means for bulk setup of existing vendors for our extranet on SharePoint Online. One of the biggest issues with the current flow for adding external users is that the invitation emails get sent from Microsoft and the content is mostly static. In my experience, many external users may disregard the email as junk mail or their email servers may even flag it automatically as such. External users expect to see emails from your domain, not Microsoft's. This script will send an email via your Exchange Online with the content of your choosing (including HTML.) The CSV file should contain just one column of data, external users' email addresses, named Email.
The script can be found at this link on Gist.
By default on SharePoint Online, the access request email for a new web gets set to the user who created that web. This may be fine for some organizations where a dedicated user is creating each new web and the same user will handle all access requests. For my organization, we wanted the access requests to be sent to an email address on our help desk application that generates a new ticket. Since we already had many webs in place, I decided to write a script to loop through all of the site collections and reset the email address for each web to our help desk email.
The full PowerShell script can be found here: http://ift.tt/1T8uhWv
To begin, go to the Office 365 group that you would like to connect to Slack. Click on the Connectors button.
From the list of connectors, click the Add button next to Incoming Webhook.
You will now be asked for some cosmetic choices for how the connected messages will be displayed within the group. Fill in the Name textbox. You can also choose to override the default image used for each conversation. All of the connected messages will show up as conversations in the group with Incoming Webhook as the sender. The messages themselves will be embedded in that conversation and will use the name and image chosen here. When you are satisfied with your choices, click the Create button.
The settings will be saved, and you will be given a URL. This URL will be needed to configure Slack to send messages to the group. When you have saved this URL somewhere safe, you can click the Done button.
A conversation will be posted to the group stating that the Incoming Webhook connector has been added to it.
With the Incoming Webhook URL saved, go to the Slack channel that you wish to connect to your Office 365 group. Click on the cogwheel button near the top of the page to access the Channel Settings.
From the Application Settings menu, click on the Add an App or Custom Integration menu item to go to the App Directory.
The App Directory contains all of the apps that may be added to Slack. Use the search box to find the Outgoing Webhooks app.
The Outgoing Webhooks app page will list the various teams that you have joined in Slack at the bottom of the page. If your team isn't listed, click the Sign in to Another Team link to login for that team. Once the team you desire is listed, click the Install button next to it.
You will be asked to confirm the addition of the Outgoing Webhooks Integration to your team on Slack. Click the Add Outgoing Webhooks Integration button.
Confirming the installation of the app will bring you to the Settings page for the app. I won't go over all of these settings, but I encourage you to explore them further using the links in the References section at the end of this blog. The settings we are interested in can be found in the Integration Settings section. Scroll down to it.
For the Channel field, choose the channel that you would like to monitor for messages. You can include Trigger Words if you like to filter what messages are sent, but I have decided to pass all messages to the Office 365 group. Add the Incoming Webhook URL that you saved earlier to the URL field. The field allows multiple URLs if you would like to send to more than one webhook. Fill in the Name field and customize the icon if desired. When you are finished, click the Save Settings button.
A message will be posted to the channel stating that you have added an integration.
With both applications properly configured, you are now ready to test the connection. To do so, simply post a message in the Slack channel.
Within the Office 365 group, you should see a New Activity notification appear on the Conversations button near the top of the page to indicate that new conversations have been added to the group. Click on the Conversations button to see the new conversations.
You should see a conversation with the test message embedded within it using the name and image that you chose during the configuration process.
If you have any questions about this blog or would like to discuss Office 365 Group Connectors in more detail, I can usually be found in the SharePoint Community chat room during the week. You can also reach me on Twitter.
Comments are in the script...
# Location of CSOM assemblies
# (from OfficeDev repo on GitHub: http://ift.tt/1MFijPt)
Set-Location "C:\Users\pchoquette\Source\Repos\PnP-Sites-Core\Assemblies\16"
# Generally required for any CSOM operations
Add-Type -Path (Resolve-Path "Microsoft.SharePoint.Client.dll")
Add-Type -Path (Resolve-Path "Microsoft.SharePoint.Client.Runtime.dll")
# Required for CSOM operations involving Document Sets
Add-Type -Path (Resolve-Path "Microsoft.SharePoint.Client.DocumentManagement.dll")
# Modify the details in this section to correspond to your Web on SPO
$ctx = New-Object Microsoft.SharePoint.Client.ClientContext("http://ift.tt/22wRMiZ")
$password = Read-Host -Prompt "Enter password" -AsSecureString
$ctx.Credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials("pchoquette@starcrossed.ninja", $password)
# Modify this line with the title of your Document Library
$list = $ctx.Web.Lists.GetByTitle("Documents")
$ctx.Load($list)
# You could modify this line if you want the Document Set to go into a subfolder instead
$parentFolder = $list.RootFolder
$listContentTypes = $list.ContentTypes
$ctx.Load($listContentTypes)
# Modify this line with the Content Type ID for your Document Set
# You can get this by going into the Content Type Settings and copying it from the URL of that page
$myContentType = $listContentTypes.GetByID("0x0120D520000535852D838B324FA8890A7BB22EE31F")
$ctx.Load($myContentType)
$ctx.ExecuteQuery()
#Modify this line with the Title for your new Document Set
[Microsoft.SharePoint.Client.DocumentSet.DocumentSet]::Create($ctx, $parentFolder, "Whatever document set name you want goes here", $myContentType.Id)
$ctx.ExecuteQuery()
SharePoint 2010 Workflow includes an action called Lookup Manager of a User. This action was not included in SharePoint 2013 Workflow. The purpose of this blog post is to show how that action can be achieved in a SharePoint 2013 Workflow. To do so, we will make a call to the REST endpoint for the User Profile Service. Examples of such calls can be found in a link in the References section.
I will not go into great detail about how workflow app permissions work. I have included some links in the References section that cover the subject better than I can. Access to the User Profile Service is not given to workflows by default, so we will need to elevate permissions.
The diagram shows the default permissions on UPS for the workflow app and the current user. Because both App and User share the None permission, the workflow will run with None permission on the UPS web service.
If the workflow app's permission is elevated to Full Control, it will look like the diagram. The highest permission shared by both the workflow app and the user is Read, so the workflow will run with Read permission on the UPS web service. This is ok, but it is not the best practice. It gives the workflow more permission than is required to perform the operation in our example workflow.
Update: Diagram is missing Edit in the App circle.
If the workflow app's permission is elevated to Read, it will look like the diagram. The highest permission shared by both the workflow app and the user is Read, so the workflow will run with Read permission on the UPS web service. This is the "sweet spot" because we are not giving the workflow app more permission than is required.
To elevate the workflow app's permissions for the User Profile Service, we must provide the appropriate Permissions Request XML. That XML follows the schema for the app manifest used by SharePoint apps. The References section contains a link that details the schema. The Permissions Request XML that we will use is:
<AppPermissionRequests><AppPermissionRequest Scope="http://sharepoint/social/tenant" Right="Read" /> </AppPermissionRequests>
The feature that we would like to access is requested in the Scope. In our case, we would like tenant-level access to the social features. A link in the References section lists all of the possible Scopes.
Once we have our Scope, we need to assign the level of access that we require for it. This is done using Right. We are just getting the manager for a user, so we will only need Read access.
Postman is an extension for the Chrome browser that lets you work with REST easily. I will not go into detail about the extension itself (more information can be found in the link in References.) The call that we will need to make to the User Profile Service using Postman is shown. An example of the output is also shown.
For this example, we will create a simple site workflow using SharePoint Designer 2013.
You'll need to create these variables for use later in the workflow:
Add a Build a Dictionary action. Set the output to the requestHeader dictionary variable. Click the ... to open the dialog for adding dictionary items. You will need to add an item as follows:
The Accept header will tell the REST web service to return the response in JSON format. This is required so that Workflow Manager can process the response and store it in a dictionary variable.
Add a Replace Substring in String action. Set the output to the user string variable. Set the strings, from left to right, as:
Update: Screenshot contains a typo. A semicolon was used instead of a colon for the first string.
Add a Replace Substring in String action. Set the output to the user string variable. Set the strings, from left to right, as:
Add a Call HTTP Web Service action. Right-click the action and choose Properties from the context pop-up. In the Call HTTP Web Service Properties dialog, set the following items:
Optional. Add an If condition to check the responseCode string variable for possible errors.
Optional. Add an Else branch to the If condition if you would like to check for errors.
Add Get an Item from a Dictionary action. Set the output to the manager string variable. Set the variables, from left to right, as:
Add a Log to History List action. Set the message to the manager string variable.
Optional. Add a Get an Item from a Dictionary action if you would like to check for errors. Set the output to the errorMsg string variable. Set the variables, from left to right, as:
Optional. Add a Log to History List action if you would like to check for errors. Set the message to the errorMsg string variable.
Add a Go to a stage action. Set the stage to End of Workflow.
From the SharePoint site where the workflow was created, navigate to Site Settings > Site Actions > Manage site features > Workflows can use app permissions. This feature must be enabled to allow the workflow to use app permissions.
From the SharePoint site where the workflow was created, navigate to Site Settings > Site app permissions > Workflow. A portion of the App Identifier for the workflow app (between | and @) will need to be copied to the clipboard as highlighted:
From the SharePoint site where the workflow was created, navigate to the following URL:
Fill in the form as:
<AppPermissionRequests><AppPermissionRequest Scope="http://sharepoint/social/tenant" Right="Read" /> </AppPermissionRequests>
The workflow app must now be trusted using the new app permissions. Since the scope was set to the tenant level for social, a tenant admin will need to trust this app. I haven't tested what the minimum requirements are for this example. Feel free to experiment and leave comments!
Peter Gibbons will be our guineau pig. As you can see from his user profile, his manager is Bill Lumbergh.
While logged in as the test user, the workflow is started.
The result in the workflow history shows the manager for the test user was retrieved successfully.
This blog post showed how to retrieve the manager for a user in a SharePoint 2013 workflow using the social features of SharePoint. The concepts provided here can be expanded upon to use other features of SharePoint that do not have native workflow actions. Explore the links in the References section for more information on how to access those features.
If you have any questions about this blog or would like to discuss workflow app permissions or the Call HTTP Web Service action in more detail, I can usually be found in the SharePoint Community chat room during the week. You can also reach me on Twitter.
One of the neat features that is available in on-premises SharePoint but not in Office 365 is the email-enabled list. This feature allows a list to have a special email address that can receive mail from users. By default, the emails will then be stored in that list, but custom processing of the emails can occur using an event receiver. A common example of that is using an event receiver to strip out attachments from incoming emails and store them in a document library.
This blog post will implement a work-around for this feature using the new Azure App Service. More information on the service itself can be found in the links included in the Reference section at the end of this blog post.
Send an email to the account you used to authorize the Office365 Connector.
As you can see from this basic example, the ability to process incoming Office 365 emails with SharePoint online is easy to setup using Azure App Service. More robust solutions are definitely possible by expanding on the skeleton Logic App provided in this blog post. I am excited about this new tool for creating solutions for Office 365 and SharePoint, and I look forward to learning more advanced techniques for using it.
If you have any questions about this blog or would like to discuss Azure App Service in more detail, I can usually be found in the SharePoint Community chat room during the week. You can also reach me on Twitter.
