I’ve recently been experimenting with turning wooden birds as a way of using up some odd scraps of wood and it’s been a fascinating journey to see how I can represent a mixture of species in a number of ways. The image below is a stylised version of a Wader, and I’ve recently been working on Robins and Wrens with a mixture of success.

The IT ‘Maker’

In the IT world, the word ‘Maker’ most often means putting out some content on YouTube, or creating an App in PowerApps but for me it also means ‘making’ knowledge and ‘making’ it available to people to consume. As a consultant this has often been part of my day to day role, with me creating and sharing knowledge with the clients that I’m working with. This has often meant some long hours, mixed between travelling, prepping for conferences and working with Clients.

For those of you that have read my blog in the past, you’ll know that I had a major life event at the end of 2019 that put me in hospital for heart surgery and took me out of commission for several months. I made a slow return to work and was actually helped by Covid as that forced a longer spell of recuperation than would actually have been possible without the pandemic.

As the pandemic started to die down, I had written a few articles and was back to full time work with my employer Trustmarque. However I felt myself dropping back into some of my previous bad habits. So I decided it was time to make a number of lifestyle changes. The easiest of the changes was adopting some of the M365 tools to help me manage my workload and I hope to write about some of these soon. (For the curious, I’m talking about things like using To Do to manage my tasks list and help reduce stress by curating it regularly using MyDay, being disciplined with my use of Outlook, using Power Automate to monitor my Inbox for key messages using a VIP/Subject list in M365 Lists (And even a bit of sentiment analysis!)).

Making a positive change

By far the biggest change however was to step away from the Consulting lifestyle at the end of 2022 and to take an Associate Director role with WTW, looking after a large M365 platform (along with a number of smaller tenants) that draws on my Multi-Geo expertise and other areas of my M365 skillset on a daily basis.

It’s been an interesting mind switch from Consultant to Customer and I’m really enjoying the challenge and the ability to not just flex my existing M365 skills, but to also grow in areas that haven’t traditionally been part of my skillset, such as Exchange Online.

I’m still committed to the Microsoft 365 Community, continue to speak at events and continue to maintain my MVP status. Part of my reason for joining WTW is their attitude to ‘making’ knowledge, sharing internally, valuing my MVP status and supporting a healthy work life balance. I regularly present internally on making use of the M365 tools to help manage your workflow, your life balance and generally trying not to end up where I did at the end of 2019!

Looking forward into 2024, I have a number of speaking engagements line up, with a return to North America to speak at NACS in early April, followed by a few more CollabDays events throughout the year (1 confirmed, several submitted!)

Paul.

The post Getting back to being Maker – making more content appeared first on Blog of an overweight SharePoint addict.

Picture the following approval process:

1. User submits a Document request in a SharePoint library and selects the first approver.
2. An approval task is created and passed to the First approver.
3. The First approver decides to either Reject or Approve the document and then chooses the second stage approver.
4. A new approval task is created for the second stage approver.
5. The Second stage Approves or rejects the document
6. Document status is updated in SharePoint.

On the face of it, it’s a fairly straight forward requirement, however in an Approve action we can only capture the Outcome and Comments from the first approver, so there’s no easy way to capture a selection of the next approver (Or any other information for that matter).

The easiest resolution for this is actually to look at using Outlook Actionable messages with Adaptive cards, which would allow us to capture additional information. The only downside to this is that we would need to handle the Adaptive Card response via an HTTPS Flow trigger, which is a Premium connector! In this environment, the client doesn’t have access to Premium Connectors which rules out that option.

Dynamic second stage approvals without premium connectors?

The work around that I suggested, does require that the list of approvers for the second stage be available at the point that the workflow is triggered. For this solution we decided that using a SharePoint configuration list provided the functionality that we needed and would meet the business requirements that we captured. The approval process becomes:

1. User submits a completed Document request in a SharePoint library and selects the Approval Group from a drop down.
2. When the flow triggers, a lookup is made against the approval group to get the First and Second stage approvers.
3. A Custom Response Approval Action is launched to the First Approver, with the  possible Outcomes built to include the Second Stage approvers. This results in the following possible Outcomes.
   • Reject
   • Approve – Send to Second Approver A
   • Approve – Send to Second Approver B
   • etc
4. Wait for the first approval outcome.
5. Create a second stage approval using the e-mail selected in the First Approval outcome
6. Wait for the Second Stage approval
7. Document status updated in SharePoint.

To show this approach in a working manner for this post, I’ve built the following:

• A SharePoint Document library with content approval and a single Lookup column to a configuration list containing the First and Second stage approvers.

• A SharePoint list with the relevant First and Second Stage approvers with a useful Title field.

We could just as easily have used the users Line Manager and then make a business decision in the flow based on the Line Managers department from their profile (with of course a catch all option for when AD doesn’t have the information!), but I wanted to keep this simpler for now to show the mechanism in action.

Building the flow

We start with a simple Selected File trigger, This allows the user to select a file and then use the context menu to submit the file for approval.

Immediately after, we pick up the selected item using a Get Item action. This gives us access to the file path and other useful info later. The next step then uses a Get Items action to select the correct Approver group from the configuration file list.

The filter query uses the Title from the lookup field in the source Item to filter the configuration list result. Watch the ‘’ around the dynamic data! (In our sample data above, the Title should equal “Finance Tier 1” or the other group name value. Once we have that item, we just need to parse it using a Parse JSON action to make it useful.

I usually build the schema for these from a first run of the Get Items action, using the Generate from Sample option. It does sometimes however provide a very rigid schema that may not meet your needs as this one didn’t. I had to remove a number of data types and required fields from the schema to make it work every time.

If you find yourself playing with JSON much, I heartily recommend reading John Liu’s post “A thesis on the Parse JSON action in Microsoft Flow” where he dives deeply into the issue with this action and it’s schema.

Next up is a couple of Initialize Variable actions, the first to immediately set the First Approver e-mail using the Expression

body(‘Parse_Approvers’)[‘value’][0][‘FirstApprover’][‘Email’]

This takes the output of our Parse JSON method, extracts the first item in the Value collection returned (we know we’re only pulling back one item!) and then gets the value of the First Approver email field and sets it as the string value of the variable. The second action just creates an empty container ready for us to use later in the flow.

And then we need an Array to hold our Custom Responses to be passed into the Approvals process. At this point, we add in any ‘static’ options that we want included, in this case the Reject option.

The next step is where the dynamic approvers comes in. We’re going to process the Second Approvers field from the configuration item. This is a multi-select People field in SharePoint, allowing us to select a number of user accounts. The only caveat really is that their e-mail must be populated. So far for this demo I’ve tried with up to 3 people selected but I see no reason why this wouldn’t work for more, depending on how the App and E-mail handles the larger number of options (You’ll see this in a short while.)

First we add an Apply to Each action and set the target of this to the following expression:

body(‘Parse_Approvers’)?[‘Value’][0][‘SecondApprovers’]

This addresses the first Item in the query to the config list (again, we know we’re only returning the one item, so this is safe.), we then get the Second Approvers collection. Then in an Append to Array action inside the apply to each, we use the following expression to pull out the e-mail of the Second Approver.

items(‘Process_Second_Approvers’)?[‘Email’]

This is then concatenated with the text “Approved – Send to “ to form the response object that we need.At this point, we know have everything that we need to trigger our first Approval process and wait for the outcome.

You’ll notice that I’ve switched the Response Options from individual items to a single block, this allows me to pass in the AuthEmails array that we created earlier. The rest of the information is straight forward, we pass the e-mail of the first approver, then a link to the item and it’s title. You can of course use the Details box to pass in more detailed content using Markdown.

At this point, an approvals process is kicked off and the First Approver will receive a notification by e-mail and directly in Teams if you have the Approvals app installed (Which is well worth doing!). The dynamic responses we put into our response block show up as choices in a drop down on the Approval app and as individual drop downs in the e-mail. Sadly the e-mail does NOT work as I’d have liked for this. It would certainly be better as an individual drop down as per the app.

With those issue aside, the next step in the flow is to process the first approval, and this is a simple matter of checking to see if our outcome was a Rejection. If it was then we can do something with the result, such as set the content approval status in SharePoint and notify the requestor. If the approval is granted and sent to the next stage, then you may want to update a status field before moving on. I’m showing that using a multi-line text field and just appending a message onto it.

As we move down the approval route, the next step is to use a Set Variable action to update the empty Second Approver Email variable that we configured earlier. This is done using the Substring function to separate out the Second Approver e-mail from the Outcome text.

substring(outputs(‘Wait_for_First_Stage_Approval’)?[‘body/outcome’],19)

In this case, 19 is the number of characters that appears in the Outcome upto and including the space in front of the e-mail address, which we know is perfectly valid, because it came from a People picker field.

Then it’s back to the approvals process, this time with a simple Approve/Reject action, passing in the extracted Second Approver e-mail. Then we wait for the Approval action to complete and then take further action based on what the Second Approver chose. As we’ve covered off the point of this post with the dynamic approvals, I won’t dwell on the closure actions of this e-mail as you’ll have differing needs based on your scenarios.

In Summary

For me one of the gaping holes in the Flow no-code story, is the ability to capture information from an end user during a process using simple actions. I’d like to be able to not just ask for approval on an item, but also pass simple questions for additional info, maybe by passing a choice list in an action. Yes we can achieve this through Actionable Messages but these require premium connectors which the majority of my clients won’t have access to. I’d also like to see some consistency between the e-mails and the Approvals app. As you’ve seen in the example above, the E-mail options when combined with custom responses don’t present very well to the end user and I hope this is something that gets amended at some point (I’ll be raising this as a bug with the product group tonight!).

But overall, I was happy that we found a solution to the client’s need that didn’t require a premium license.

The post Dynamic second stage approvals using Approvals in Power Automate appeared first on Blog of an overweight SharePoint addict.

Back when SharePoint on-premises was all the rage, there was always a need to provide a way of automating script actions for a number of reasons. Invariably this would mean that an automation server would be configured running Windows Scheduled tasks out of hours to access and process SharePoint data under the identity of a Service Account. This need has not gone away with SharePoint Online and if anything, with the advent of the Microsoft Graph the possibilities have increased tenfold along with the options for automating using App Credentials.

For me the simplest automation in recent times has been to use Azure Runbooks, we can use PowerShell, it has a simple to use Modules library for popular modules like PNP PowerShell,we can upload our own Modules for code re-use and we can run scripts for up to 3 hours without problems. It also integrates heavily with other services such as the Azure KeyVault for credential storage. The only problem with KeyVault is that it’s an additional cost and can be a little complex to setup and use, requiring Service Principals and Certificates. If we look back at how we ran our old on-premises Task Scheduler it was generally accepted that IDs and Passwords in Script files was not a good thing and the majority of people would use Windows Credential Manager to encode the credentials into safe storage against the logged on account. Luckily, we can do just such a thing with Windows Automation accounts, enabling us to share service credentials between a number of scripts/authors.

For the purpose of this article I’m going to assume two things, both of which are well documented on the Internet, so there’s no point me re-hashing them here:

1. You have an Automation Account configured in Azure that is configured to allow a limited number of people access using Access Control.
2. You have some App Credentials configured in Azure AD (A Client/Secret pair) that you wish to call the Microsoft Graph with. These must have been granted API Permissions to the Graph. (Section 2 in this Doc from Microsoft)

Storing the App Credentials in readiness for reuse.

When you open your Automation Account pane in the Azure Portal, there are a number of resources down the left hand side that you’ll be using, The section that we’re interested in for this post is under Shared Resources. This is the section where we publish Schedules for our scripts, make modules available, and more importantly let us store and share credentials and variables between our Runbooks.

When I first looked at Runbooks, I immediately jumped on Credentials and started trying to use these for my scripts, storing the App Credentials as if they were a UserName and Password. The big problem with this is that the Password is encrypted and it is very difficult to pass this into our automation calls without writing an overly complex script. The much simpler approach is to use Automation Variables instead.

“How is that secure””?” you may well ask. Well the answer to that lies in how the Automation accounts let’s you declare a Variable as an Encrypted variable, for which the value is not shown in the interface once it’s been committed. Whilst an author with the correct rights can obtain the value (which is kind of the point as we need to be able to pass a string to the Graph), it reduces the amount of visibility to a casual observer.

To add these, simply click on the “+ Add a variable” at the top of the screen and first add your ClientID as a string and hit Create, then do exactly the same for your Client Secret, but this time, click on the Encrypted toggle at the bottom of the pane, then hit Create.

You’ll notice that the boxes turn purple and when you return to the Credentials screen, you can only see the ID of the ClientID and not the Secret. With those saved, we can now turn our attention to using them in the Runbook itself.

Consuming our Automation Variables in a Runbook

This really is the simple part as we use a single Azure Cmdlet to obtain our values in readiness to plug them into the Rest call to the Graph to create our token.

Get-AutomationVariable

$ClientID = get-automationvariable  -name "OurNewClientID"
$clientSecret = get-automationvariable -name "OurNewClientSecret"

That call handles all of the decryption that we need and gives us simple string variables to inject into the Rest call to the graph (detailed in section 4 of this MIcrosoft doc) and for simplicity, in this function that I use in most of my scripts.

function get-oAuthAccessToken()
{
    Param(
        [Parameter(Mandatory=$true)] [String] $resource,
        [Parameter(Mandatory=$true)] [String] $clientID,
        [Parameter(Mandatory=$true)] [String] $clientSecret,
        [Parameter(Mandatory=$true)] [String] $loginURL,
        [Parameter(Mandatory=$true)] [String] $tenantDomain
    )   

    # Retrieve Oauth 2 access token
    $body = @{grant_type="client_credentials";resource=$resource;client_id=$clientID;client_secret=$clientSecret}
    $oauthToken = Invoke-RestMethod -Method Post -Uri $loginURL/$tenantdomain/oauth2/token?api-version=1.0 -Body $body

    return $oauthToken
}

Call this using your new ClientID and ClientSecret values, along with the following EndPoints:

#oAuth Token Endpoints.
$resourceAPI = "https://graph.microsoft.com"
$loginURL = "https://login.windows.net"
$apiPrefix = "https://graph.microsoft.com/v1.0/"
$tenantDomain = "<<yourdomain>>.onmicrosoft.com"

I hope this proves useful.

Paul.

The post The problem of storing App credentials in Azure Runbooks appeared first on Blog of an overweight SharePoint addict.

The other issue relates to time and schedule management and that’s really the crux of this post. Microsoft Teams provides a number of ways of booking a meeting, from Clicking on the Meet Now button in your personal calendar and dragging people into the call, booking a meeting in the traditional manner through Outlook by inviting people, or clicking on Meet Now in a channel to send an alert to all the users of the Channel. The one aspect that I feel doesn’t work so well is when I schedule a meeting to take place within a Teams Channel. If you’re not familiar with what I mean, take a look at the image below where I’m booking a meeting in the Teams Calendar, but choosing a Channel to meet in rather than selecting attendees.

When you hit Send, this places a booking into the Originators calendar, blocking out their time but nothing appears in any of the other Channel members calendars for them to accept/decline. Instead what we do get is a Channel message showing that a meeting was scheduled.

If we click on this to see the meeting details, we can choose Add to Calendar to “Accept” the booking and to block out our time.

The problem for end users here is that this time is only blocked out when they accept the meeting from the channel itself, unlike the default behaviour in Outlook where the time is tentatively blocked out in the calendar until the user decides to Accept or Decline the invitation. For users that rely on their calendar heavily to manage their schedule, this can become a source of double bookings very quickly.

At this point, most end users just end up adding the group members to the Attendees list which is fine in a small group, but what about when a channel has many members? The default behaviour by users is to try and add the Group name to the Attendees list which sadly doesn’t work for most Microsoft Teams because the underlying group is hidden from the Outlook Address book by default (For all Teams created after May 2018). Whilst we can override this behaviour using PowerShell, that would require IT to be involved with each group creation.

The next step is to try @mentioning the Channel or Team name in the title of the meeting and sadly that doesn’t work either. The only way to drive peoples attention to the booking is to pop into the channel and @Mentioning the Team or Channel in the same Thread as the booking.

For companies and users that are moving from a very Outlook driven experience, meetings in Channels could be a regular sticking point in the adoption path, so hopefully this tip will help drive the behaviour changes needed for Channel meetings. At least until Microsoft look at aligning the behaviours in calendar bookings between outlook and Teams.

Paul.

The post Addressing the challenge presented by Channel meetings in Microsoft Teams appeared first on Blog of an overweight SharePoint addict.

Since early March, the Teams engineering team released a much-needed improvement for this situation in the form of Notification Tags. As a Team owner, I can define several different tags that the Team can @Mention instead of using the Team or Channel name. As a result, notifications only go out to users that have that Tag assigned to them.

If we take my fictional Business Productivity team as an example, my team has specialists from across Office 365. When I post my latest blog post on how to use SharePoint Spaces, the Exchange guys probably are not that interested in being notified about it. They can still see the post in the channel, but it will not highlight it for them, and they will not get the pop-ups.

Adding new tags can be done from the Manage Users screen shown above, or from the Team context menu.

Of the two experiences, I like how the tags experience is setup on the Manage Team, however I would imagine for larger teams both experiences will be quite onerous for manual configuration so I’m very interested to see how this feature develops.  It would be nice to be able to maybe define a rule in the UI that applies a tag based on a user profile property.

I do feel that the end-user experience needs some work. Currently if an End-User clicks on the Manage Tags context option, they receive the same layout as shown above, but without the ability to create new tags or change membership INCLUDING their own membership of a Tag. For me, a crucial part of this will be self-management of tag group membership.

With regards to the use of Tags in channel conversations, these work in exactly the same way that @Mentions for Teams, Channels and People do with a nice type ahead lookup and prompt.

Overall, this is a great start with notification tags and I’m really looking forward to seeing what Teams Engineering do with the feedback so far on this aspect of the product.

For more info, see the documentation here.

The post Using Notification Tags in Microsoft Teams appeared first on Blog of an overweight SharePoint addict.

Just an FYI.. you must have Azure AD P1 for anyone subject to site sensitivity labels as it requires Azure AD Conditional Access to work!

If like me you’ve been using Site Scoped Conditional Access policies in SharePoint for sometime (Launched in Oct 2017!), then you may already have the required rules in Azure AD Conditional Access, as these were required to enable that functionality and these group scoped rules work in exactly the same way.

For those of you not familiar with Conditional Access, it’s a way of creating a set of policies that can be targeted at all or a subset of your users to control access to Azure AD Protected applications based on things like Who the user is, where they are logging in from, what device they are using and depending on your license even how “Risky” their logon is considered using AI derived algorithms.

For the purposes of what we want to achieve, we’re going to create a Conditional Access rule that covers the following key points:

1. Is targeted at a Single Test User.
2. Tests to see if the user is outside of the “Trusted locations” (e.g. outside the corporate perimeter)
3. If the rule applies, access will be granted but final control will be passed to the application for it to control access (in this case SharePoint)

It’s that final stage that provides SharePoint the granular control over whether to allow the user in with Full or limited access, or to just block them outright. This maps directly to the ConditionalAccessPolicy property that can be configured on an SPSite object through PowerShell, with the following values.

Looking at the sites created during both Teams creation and SharePoint site creation with sensitivity labels, I’m seeing the same properties being configured under the hood, so it’s safe to assume the mechanisms of both this and classic Site Scoped access policies are the same.

These map directly to the permissions found in the Sensitivity Label configuration for Sites and Groups:

Assuming that we’ve created our site sensitivity labels and created a new Team, Group or Site using them, or decorated a SharePoint site with the conditional access policy shown above, how do we create the conditional access policy to enforce those behaviours?

• Open the Azure Portal and find the Azure AD Conditional Access blade. Click on New Policy and configure the following:

• Give your new policy a meaningful name, there’s a good chance your conditional access policy lists will grow quite large!
• Apply it to your test users and select which cloud apps, If you select just SharePoint, you’ll see a recommendation that you use the Office 365 App as a selection instead, ignore this and Select SharePoint anyway, if you don’t the Session Condition that we need is greyed out.
• Under conditions, if you have Trusted Locations configured to represent your internal perimeter devices, then configure the Conditional to EXCLUDE trusted locations. This means the policy will only apply if you are NOT in a trusted location.

• In the Access Controls session, select the Session option and choose “Use App Enforced Restrictions”.
• Enable the policy and hit Create.

Now log on with your Test user from a non trusted location and try and access sites that you’ve configured with Full, Limited and Blocked access policies. You should find a mix of experiences based on each policy that you’ve set.

Note: These new policies take effect almost immediately, however if your test user has cached credentials and a valid token, they won’t take effect until that token expires, so make sure you test using an InPrivate browsing session!

The post Configuring your tenant Conditional Access for Site Sensitivity Labels in Office 365 appeared first on Blog of an overweight SharePoint addict.

Update to Site Collection Scoped policies with Site Sensitivity Labels

I’ve been talking about conditional access in Office 365 at events for some time now and whenever we talk about Site Collection Scoped policies, I’ve always said the missing link is for the End User to be able to select them without IT intervention and for this we need Site Sensitivity labels that actually do something!

For those that aren’t familiar with Site Collection Scoped policies, these can be set through PowerShell on any Site Collection in SharePoint Online, which when coupled with a suitably configured Conditional Access rule, lock down the end users ability to take certain actions based on one of three scopes.. Full Access, Limited Access and No Access.

The key blocker for me and the missing link in the whole piece has been the IT involvement step.. What user is going to create a site and then raise a call with their IT department to have the site locked down? Pretty certain the answer to that is a big resounding.. NONE!

Microsoft has been talking about Site Sensitivity Labels since Ignite in 2018 and despite seeing a few previews, we’ve not seen much about them until they announce the private preview at Ignite 2019 and then just last week on 28th February 2020, they announced that the feature had finally hit public preview… The missing link has arrived!

The missing link – Site sensitivity labels!

To enable the preview feature, you first need to read this page on docs.microsoft.com and follow the steps in “Enable sensitivity label support in PowerShell”.

Then read the preview documents from MS (available on docs.microsoft.com here.) and follow steps 2 and 3 in “Enable this preview and synchronise labels” (Step 1 was to do the PowerShell bits!)

Now you need to create or edit your sensitivity labels to include the new Site and Group Settings in the Label configuration under Classification in the old protection portal (You may find this in the compliance portal in your tenant.)

As you can see, the settings are fairly straight forward and allow you to control the privacy of the group, whether External Users can be added and what access unmanaged devices have to the site. Once you’ve configured a Sensitivity Label or 3, create a publishing Policy that contains a few test users and hit publish… (Just bear in mind, that when a label is applied to a Site or Group, only the Site and Group settings applied to the site, there is no inheritance of the label on content…so no encryption, watermarking etc!)

Then wait up to 24 hours!.. Yep seriously..it can take 24 hours for your labels to be pushed out. Mine took 14 hours in the end, so be prepared to wait.

Once the labels have been applied, you should see them in 4 main places:

• Office 365 Group Creation experience in Azure
• Teams creation experience in the Teams client (or browser)
• SPO Creation experience in SharePoint Online.
• SharePoint Administration Page (modern experience)

I’m going to dig a little deeper into the conditional access side of how this all works in my next post, but for now I want to talk about the user experience as there’s a couple of little issues currently. I’ve notified the product group of these through the MVP channels and hopefully by the time this reaches GA, we’ll have got them all resolved.

The first issue is one of confusion. As a SharePoint user, if I go to a limited access site, I get a really nice banner at the top of the page that highlights that due to the device I’m using, I’m not permitted to perform certain actions like downloading or printing.

If I attempt to go to a blocked site, I’ll receive a stern but clear access error:

If however I’m a teams user, I can access the Team quite happily, but if I try and switch to the files tab, I receive a rather nasty error that suggests someone has deleted the list or I don’t have access (which is somewhat close to the truth!)

The second issue is rather less annoying and more one of consistency. When I create a new Office 365 Group or a Microsoft Team (Option B), I can choose to use a Sensitivity Label or leave it set to None.. When creating a new site in SharePoint (Option A), you MUST select a label which could prove limiting as it then requires you to change the label if you want to change the group between Public/Private etc.

That’s all for now. In the next post I’m going to cover some of the technical controls that you need to put in place, and a few good practices to consider for the short term!

Paul.

The post Site sensitivity labels in Teams, Groups and SharePoint appeared first on Blog of an overweight SharePoint addict.

I’ve not been using Power Automate heavily in recent projects, just the odd small workflow here and there, but just recently a colleague asked me if it was possible to automate Flow Deployment.. i.e. deploy a flow with a flow?

Not being 100%, I reached out to a few friends in the User Group community and Serge Luca came back very quickly and said, “Have you looked at the Create Flow” action in the Flow Management Connector.

On the face of it, the “Create Flow” action looks very simple to use, you select your environment, give it a display name, drop in a definition and give it a state of On or Off. Simples!

Well of course nothing is that simple and in this case it’s the Flow Definition that will keep you awake. On the face of it, the definition is fairly simple JSON that complies roughly to the following:

To test this out, I used the “Get Flow” action to get a valid definition of a flow attached to a SharePoint Library, then took the output of this and piped it directly into the “Create Flow”. This however didn’t work until I realised that I needed to include the Connection References from the received flow too.

Note: Clicking on the icon to the right of the references collection drops it down to a single box for a collection reference.

With all the elements in place, the flow runs perfectly, creating a new copy of the flow attached to the same SharePoint list. Ok great.. we’re now getting two email alerts instead of one!

The real power in this scenario now, would be to take the source Flow and to re-attach the trigger connection to a new library in a new site collection. The Scenario for this is that we’re using a mixture of Site Designs and PNP to create a particular type of site and we need to include a flow on each site that is built. As flows currently do not get included in site designs, the only option is to try and do this through automation, by calling the flow after the PNP work is finished.

To test this theory, I took the output of the Flow Definition step in our test email which is JSON format text and edited it in VS Code. Looking at the structure of the workflow, the only thing I need to change is a few elements in the trigger. These are:

/inputs/path

/inputs/queries/folderpath

I updated this with the correct new values and then pasted the whole JSON back into the “Create Flow” action, only to be met with a Big red dot on the flow checker. Looking at the error it reads “Correct to include a valid reference to ‘Get_my_profile_(V2)’ for the input parameter(s) of action ‘Create_Flow’”

But I’m not using the Get Profile action in this flow? However I am using it in the source flow that we’re copying. On Examination when we look at what’s been pasted into the “Create Flow” action, we can see that the app designer has parsed all of the text, including the parameters of the actions embedded in the workflow definition.

This had me at a bit of a loss and I toyed with the problem for a day or two before posting on the Power Platform forums and reaching out to a few people in the community. Luckily, John Liu came to my rescue and pointed to some fun he had using Geolocation for Pokemon Go! (And I love this example of using flow for fun!, click on the Tweet below to see the full trail.)

@johnnliu I’ve seen a post of yours I think that discussed the “Create Flow” action in the Flow Management Connectors.. were you ever able to customise the definition of the flow being created? https://t.co/z0expwCk3C #PowerAutomate #Flow

— Paul Hunt #MVP #Maker (@cimares) February 12, 2020

The pointers he gave me in that tweet showed me that I needed to break up and rebuild the Flow Definition. I didn’t quite realise how granular I needed to be though and in the end we pretty much rebuilt the definition dynamically throughout using a lot of Compose Actions.

As the flow will eventually be triggered by an HTML request, I started building using a Manual Trigger, capturing four key pieces of information.

· siteURL – The URL of the site that has been created

· flowName – The new name of the dynamically created flow.

· listName – The name of the list

· folderPath – Usually the name of the list (unless it’s the Documents list, in which case it’s “Shared Documents”

Note: Notice the Parameter names that we list in the Trigger action above? These are NOT the names that you find them by when addressing the JSON in the step named “Initialise SiteURL Encoded” in the next step. Instead they are labelled “text”, “text_1” etc internally! If you Peek the code you can see what I mean. This isn’t a problem when using the Dynamic data selector, only when using the TriggerBody() function.

Since I demo’d this issue as the London PPUG, Pieter Veenstra went away to find a way to correct this issue. It does mean exporting and re-importing the flow, but it does resolve the naming problem!

Read Pieters blog post from this link.

After this, we have some setting up to do. First we get all the lists and libraries from the site (I realised after I wrote this, that this step is NOT needed as we can just call for the library ID using an HTTP request!) and also capture the Site URL as an encodedURIComponent so that we can safely embed it in the JSON.

Then we get the target List from a SharePoint Rest call so that we can use the ID GUID from the list in our definition (this is also URL Encoded as per the default definition from Flow).

Following this, the Get Flow action allows us to grab a copy of our Source flow. For our scenario, this flow is permanently attached to our Template site which is kept to allow for updates to the Site Design.

It’s at this point where things go a little crazy. During the reverse engineering that I did, I found that using a single compose action wasn’t suitable as I kept getting crazy errors like: “The flow cannot contain unsupported parameter function expressions” which I traced back to some of the parts of the definition that I wasn’t intending to change.

To get around this, I had to break out the individual elements of the JSON definition into single Compose Actions, then bring them all together at the end into a new block of JSON. There might be more efficient ways of doing this using SetProperty like John does in his Flow, but I just haven’t had as much exposure to the Expression functions yet and this worked for me!

The first two actions use the same method to grab the relevant portions of the JSON from the “Get Flow” action. In the Inputs field, we use the expression “body(‘Get_Flow’)[‘properties’][‘definition’][‘parameters’] to grab the block of data that we want.

As we’re not making any changes to Parameters or Actions at this point, we don’t need to be any more granular than that. These blocks will just be added back into our Flow Definition at the bottom of this step.

The Triggers section is where it becomes a little more difficult, so we start by building up the sections that we do want to amend, Path and Query.

For the path, we inject our URL encoded Site URL and the ListID into a new string that replaces this line from the original definition:

“path”: “/datasets/https%253A%252F%252F<tenant>.sharepoint.com%252Fsites%252FTestSiteForPen/tables/ecdd0b51-6f77-42fb-8aad-63e2312a95fe/onnewfileitems”

For the query, we inject the folder path (collected at the start) into a JSON object string.

Then finally we grab the Host and Authentication elements in their entirety as we’re not making any changes to these either.

With all of these elements in place, we can now build up the new trigger element as a new block of JSON, injecting the relevant elements as needed (Note the “Outputs” come from the relevant Compose action).

And then finally, we create a new Flow Definition bringing together all of the elements:

And then the finished “Create Flow” action

With this saved, I created a new site collection, then called the flow, passing in the URL, library name and the other required information. This created the Flow which duly triggered when a file was uploaded into the library.

Then I had a drink to celebrate!

The post Using PowerAutomate to deploy PowerAutomate (Flow deploying Flow)… Sounds like Inception? appeared first on Blog of an overweight SharePoint addict.

That said, I was stoked to receive an e-mail from the SharePoint Conference team, to say that my session on conditional access had been selected for presentation in Vegas at SharePoint Conference NA – SPC20 in May. I know that they get a lot of submissions of quality sessions from some of the most exceptional speakers from around the world (just take a look at the speaker list so far! SharePointna.com), so to be selected to speak is certainly an honour for me and one I am truly grateful for!

I’ll be presenting a session on using Conditional Access to control access to content in Office 365. This is certainly one of my favourite sessions to deliver and I’ve been giving a session with this title for over a year now, but so far nearly every delivery has been different. We can only thank Microsoft for this as their continual evolution of the platform has meant that I’ve had to continually adapt this session to address the changes and improvements they’ve made in both perimeter security and content security for organisation users, admins and external guests.

I find the subject of access into Office 365 a great topic to speak with customers about. There’s this recurring perception that the cloud is unsafe and that your own on-premises data centre is safer, but I like to challenge that statement in discussions and understand why the person takes that viewpoint. In my experience it’s not the cloud platform that is unsafe, it’s generally the way that it’s been deployed and how access is controlled and granted. Conversely if we look at the perimeter controls on an enterprise data centre, there is generally very little that can match the scale of any cloud provider when it comes to perimeter security and intrusion detection.

On the subject of perimeter security, I read a great security blog last year (apologies but I can’t find the source now) that used the analogy of the Greeks in the battle of Thermopylae, stood outside their mountain fortress, relying on the walls behind them to protect them as they fought off the marauding Persian army. The problem is, they forgot about the locals who had been farming goats in the region for hundreds of years. The Persians used this local knowledge to find these goat paths to get behind the Greeks and destroyed the rear guard, leaving King Leonidas to defend the retreat of the Greeks with 300 Spartans.

In the context of our data centres, the local knowledge is our users at risk of social engineering attacks, malicious e-mails and documents. The goat paths are the holes we need to make in our perimeter for things like ADFS or access to on-premises data for remote workers.

This is where the cloud configuration of a service like Office 365 and Azure can play a very important part in how we control and govern this access. With content stored in Office 365, we get the native protection of the Microsoft data centres, with the massive economies of scale resulting in large scale security infrastructure and a service that learns from millions of signals a day across all of the tenants around the world. Couple this with the duplication of data and the protection such as self-service restores in OneDrive and SharePoint to help mitigate the effects of Ransom Ware attacks.

The signals and information that we receive by being part of the Microsoft eco-system can also be used as we look into the user access side of things. We can make decisions based on the risk of the user’s logon, where they are coming from, is this a usual behaviour for them etc. Take for example a user logging in from a coffee shop in a strange city. If this location is a known location that sources malware attacks, we can use conditional access to restrict the users permissions or completely blocking them out altogether if we choose.

During my SPC20 session in las Vegas, we’ll take a look at what we mean by “Conditional Access”, looking beyond the conditional access product provide by Microsoft and understanding how such access can be controlled at the various licensing levels, from the basic options with ADFS, using location blocking in office 365 through to the more advanced options available through the EM+S E3 license and Intune. We’ll round out the session with a look at controlling guest access using Terms of Use and managing Privileged Identities via the EM+S E5 license.

I hope you’ll join me at SPC20 in Las Vegas in May to absorb the combined knowledge of some amazing people in the warmth of the desert sun at the amazing MGM Grand. If you’d like to save $50 of your registration, use the discount code HUNT (in caps) or click on this link to learn more and register.

Paul.

The post Back to work with a bang and great news that I’ll be in Vegas in May @ SPC20 appeared first on Blog of an overweight SharePoint addict.

Between preparing for these events, doing my normal day job and then travelling and presenting there were a number of signals that I was given that something wasn’t quite right. Excessive tiredness, a reliance on heartburn medication all of which I put down to just being a bit run down with everything going on, but with my 20/20 Hindsight turned on, I know now that I missed a whole bunch of warnings that life was about to change significantly.

Thanks to the BA pilots strike, I ended up flying out to Helsinki at the tail end of September a day early so that I could miss the strike (that subsequently got cancelled after I changed my flights) and work remotely for my client. This added to the stress of the travel a little as it meant two laptops and an extra night away from home. It did however mean that I got to spend the first day exploring Helsinki with my good friend Jussi Mori, a fellow Microsoft MVP based out of Helsinki.

During this exploration time, Jussi introduced me to a fairly new transportation method in Helsinki, the Rental Scooter. The rental scooter phenomenon is popping up in cities all around the world where laws permit, and they appeared in Helsinki back in Spring of 2019. Rented using a mobile phone app, the biggest complaint about the scooters is my favourite feature and that is they do not need a docking station. You can pick up and drop off the scooter at any location (within certain Geo-fenced restrictions, which also includes zones where speed is limited, and parking of scooters forbidden).

The problem here is that not every user is a good scooter user and complaints across the internet talk about how scooters are just thrown down in the middle of pavements, blocking disabled access and making the streets look untidy. I used the scooters a lot during my trip and I always tried to make sure that I left the scooter when I finished, parked reasonably and well out of the way of other pavement users.

At this point, I guess you’re probably wondering how this technology saved my life? As with most stories of this ilk, it starts with a drink. Traditionally after a SharePoint Saturday event, there will always be a SharePint, a tradition that has been around almost as long as SharePoint itself. Helsinki was no different and after the official SharePint had finished, a number of us decided to jump on scooters out to a fabulous Bar on the outskirts of Helsinki called Löyly. Following the coastal route from the centre of town, it’s about a 15 minute ride on the scooters at full pelt and with the added excitement of a couple of drinks it was a fun ride. All of us arrived safely and we grabbed an outside table under blankets and heaters and had a few more drinks.

By the time the bar closed, it was just gone midnight and we’d had more than a few drinks at this point, so the sensible decision was taken to walk back rather than ride. The direct route back through residential Helsinki was much shorter than the coastal route, so we were only looking at about a 2 mile walk. And it was during the start of this walk that I started to have problems.

Whilst I’m overweight, I’m still reasonably fit as I walk a lot when working in London. I don’t usually have problems walking any distance, so when I started getting some breathing difficulties it took me somewhat by surprise. I found myself falling further and further behind and the rest of the group had to wait for me. I didn’t get any pain in my chest, just this tight wheeziness and an inability to catch my breath. When I stopped walking it eased and I started wondering if I was developing asthma. Whilst considering this and just as it was getting uncomfortable again, I came across a fully charged Tier scooter, dumped unceremoniously at the foot of someone’s garden path! Without thinking about it, I whipped out the mobile app, rented the scooter and jumped on it. Problem solved.

Catching up with the main group, I rode the scooter all the way back into central Helsinki, eventually splitting from the group and heading back to my hotel whilst they continued into the early hours.

On my return home I decided to get some medical advice, thinking that I may need to have an inhaler. The doctor on hearing my story, referred me to the Rapid Access Chest Pain Clinic (I did point out that I didn’t have any chest pain!) at our local hospital. I went to see them (after a couple of other events that I was booked for (in hindsight that wasn’t the best decision!), and they performed a stress ECG test. Basically, this sees you wired to an ECG and placed on a treadmill. After 5 short minutes of this, they stopped the test and told me that I wasn’t going home. I was transferred to a ward and prepped for an angiogram.

I’m always an optimistic person and having discussed the results of the stress ECG and understanding I had at this point got a condition called Exertional Angina, fully expected to be told to take 2 pills a day and change my lifestyle. What I didn’t expect was the result of the Angiogram to tell me that I needed Open Heart Surgery, specifically a Coronary Heart Bypass Graft, where they use pieces of other veins to replace the blocked arteries that feed the heart and I did not expect to be told that it needed to be done fairly urgently. According to the doctors, had I not jumped on that scooter in Helsinki and had carried on trying to walk back, there was a distinct likelihood that my angina attack would have escalated into a full cardiac arrest, which at 1am in a quiet residential area of Helsinki would have had a low chance of survival.

I’m now currently in my fifth week of post op recovery and I’m pleased to say that I’m doing well. I can now sit at the computer at least long enough to type this up and to submit some sessions for events in the new year. My company (Trustmarque Solutions Ltd) have been very supportive through this process and have ensured that have time and support in place to fully recover. The current plan is to aim to return to work during January and I aim to return to doing community events in March 2020.

In addition to the support I’ve had from work, family and friends (and of course my outstanding wife Billie), I have to call out the amazing messages of support that I’ve had from my extended family around the world in the Office 365 community. So far, I’ve kept news of my condition to a reasonably selective group of around 200 friends on FaceBook, but as I’ve had to pull out of a couple of events such as SPS Leicester and the Thrive conference, word of my illness has got around the community and I’ve had some lovely messages from people. This support from the community is just one example of why I love doing what we do, it goes beyond the technology and is a reward in it’s own right and there’s just too many individuals to call out with direct thanks here. You all know who you are and I look forward to thanking you in person at events in 2020!

The post The time a disruptive technology saved my life in Helsinki appeared first on Blog of an overweight SharePoint addict.