Banner - Business User Group meetup

Event recap: “Bots in the Real World: Truth, Hype and Demos”

A lot of us long for the day we can kick up our feet and let Cortana manage our professional lives. Or we worry that our jobs will be stolen by bots.

This month at the Melbourne Office 365 Business User Group (BUG), they took a shot at cutting through the hype and getting to something practical.

Facilitated by Engage Squared and hosted at Microsoft’s office at Southbank, they had 90+ registrants and a full house on the day.

Host Jack Hendy (an adoption specialist at Engage Squared) kicked off the session with…

“What’s new in Office 365”:

  • Cortana can be tagged in emails to help arrange meetings (Your personal assistant, just @Cortana)
  • New Q&A functionality in Yammer (Lets you mark answers to questions)
  • Microsoft Whiteboard App (Allows you to add reactions, integrates with SurfaceHub and has “ink beautification”: Bad handwriting? No worries)
  • PowerPoint-designed slides (Make your company’s branding consistent using custom templates and automated suggestions)
  • New customisable and unified Microsoft Search (A reason to use Bing)

AnswerBot: Going with the Flow

Their first presenter, Jason Soo from law firm Hill and Wilcox, introduced us to the basic Question and Answer (QnA) bot, enhanced with Flow. The bot solution leveraged Flow’s approval workflow, allowing the bot to update its QnA knowledge base with new answers to new questions.

This bot/Flow duo:

  • Captured questions from a Yammer group (this could be any ‘front door’/entry point, such as an intranet or website)
  • Answered questions parsed through the Azure QnA Maker
    • If the question is “like for like” or the answer has a high degree of confidence (an adjustable setting in QnA Maker), the response is posted in Yammer
  • If the confidence score is low or no match has been found, an approval flow is triggered which then presents a subject matter expert with the question, a potential answer and an option to submit another answer
    • This can be extremely powerful for enterprise-wide bots, as subject matter experts can be tied to different knowledge bases (owned by different portfolios/organisational groups), all connected to one bot
  • The answer, once accepted in Yammer, is automatically added back to the associated knowledge base

Apart from the ‘learning’ AnswerBot is capable of, she can be used to drive uptake and draw audiences to platforms like Yammer.

Jason also showed how he was able to set up AnswerBot (Flow not included) in 5 minutes using an Ignite video found here.

Codee: Journey from FAQs to Teams Governance

Next on deck was Adrian Tan and Sarah Aquilina from the Department of Health and Human Services (DHHS). Codee started her journey as an Office 365 FAQ assistant and is currently on the road to becoming much more, starting off with Teams Governance.

How do you transition an organisation of 13000 people[1] off Lotus notes and onto Office 365 while keeping up with basic (but necessary) queries?

The answer was Codee (formally known as BAE).

Codee is a basic QnA bot (living in Teams) that also leverages the Azure QnA Maker. Sarah, a non-technical stakeholder, showed how she was able to use the QnA maker to manage and improve the bot without needing help from the rest of her team.

The related cost of Azure consumption and virtual machines in the cloud was also discussed. The group agreed that different business problems called for different levels of investment and the free options provided by Microsoft to trial bots made it easy to get started. Generally, the ROI associated with the automation of answers to high-volume, repetitive questions was seen to pay for the initial outlay quite quickly.

Adrian, the program manager at DHHS concluded that paying the monthly cost to maintain Codee allowed his team to focus their efforts on activities more impactful to the business.

Codee is currently being developed to have the ability to create Teams at DHHS and asking for Teams names, owners and settings during the provisioning process.

ZELA: The Truth and the Hype

Elaine Van Bergen finished off with the (not so cold) hard truth: bots are just apps.

They’re apps that can be used to supplement other content in areas such as websites, Yammer and Teams.

In its more advanced stages, a bot:

  • Can be used to greet and attempt to assist users (and refer them to humans if sentiment analysis or the specificity of the questions warrant it)
  • Can be used with voice recognition or integrated with IVRs to provide feedback and activate workflows

While these examples are exciting, Elaine emphasised that while it’s easy to create bots and get immediate returns, any complexity or customisation will find you needing developers. It was also recommended to run basic bot projects before delving into more technical projects.

Elaine then introduced ZELA to the group.

ZELA is Microsoft’s internally built bot that assists with high-volume, low-risk queries to the legal department which previously lead to bottlenecks. ZELA helps with:

  • Answering self-help queries such as “where can I find…”
  • Client requests for support
  • Answering general, front-line questions from clients

The group agreed ZELA was a good example of fast value-for-effort and was intrigued by its use in a department as critical as Legal.


The session concluded with a prize giveaway, thanks to sponsorship by Logitech.

If you’re in interested in future Business User Group meetups, please join them and us at the next meeting!





[1] DHHS, ‘People Strategy 2020’, Department of Health and Human Services, Victoria, 2017, p 15,, (accessed 4 July 2019).

Microsoft Flow - Azure Automation

Flow and Azure Automation, working in harmony!

Microsoft Flow

Recently, the Microsoft Flow action Azure Automation was released, allowing us to interact with Azure Automation from Flow.

Although since early releases of Microsoft Flow we’ve been able to interact with Azure Automation by creating WebJobs, it has proved that many technical staff are not yet familiar with these. I believe this partly has a hand in why we haven’t yet heard the amount of integration stories between Microsoft Flow and Azure Automation as first anticipated.

To me, the integration between Microsoft Flow and Azure Automation means we can now fill in the gaps where there may not be a Microsoft Flow action available yet. It allows us to run scripts on demand or on a schedule. All that being said, let’s focus on the now.

Today, I’ll be creating a Flow that is triggered manually and requires user input; on execution of Flow it will start a run job in Azure Automation. This job will be executing a PowerShell script to reset a user’s password.

If we think of the scenario where a Desktop Support Technician is walking by the good old water cooler and a staff member pulls them aside and says ‘Hey, IT guy… can you help? I can’t login. I forgot my password… again. Can you reset my password?’ Rather than the wonderful person in support being required to go back to their desk and log back into Office 365 to reset the user’s password, they can simply enter the user’s email and execute the Microsoft Flow to reset it for the forgetful employee. Super simple! While this example is valid for the moment, there may well be an action released to reset a user’s password in the near future. But the focus of this blog post is that, while there are many actions available in Microsoft Flow, there may not yet always be one available to meet your particular business need – that’s where Azure Automation could fill the gaps!

Okay, let’s start – we will need to have an Azure tenancy, along with Azure Automation Service added. I won’t go into these basic steps as there is plenty of information about these on the web.

Right, so you’re now in Azure and you’ve added the Azure Automation Service and created a runbook. For this Demo, I’ve created a runbook called ‘ResetUserPassword’

Before we can start, we will be requiring the MSOnline Module so we can access the Office 365 tenancy, so let’s go ahead and add this in.

Access your Azure Automation account and click Assets > Modules

I can now either browse or search the Gallery to find the MSOnline module I’m looking for. Click Import and the module is now available for use.

Next, we will be required to set up our credentials for our Office 365 tenancy. From the Azure Automation left hand panel click Credentials > Add a credential. When adding your credentials, you will be required to provide a friendly name (this is important for when we are creating our script), and the username and password for the Office 365 tenancy. In this example as I am resetting a users password I have an account with Administrator privileges. Depending you’re requirement you may need to use a service account or equivalent with elevated privileges.

Now that both the module and credentials have been set up for the Office 365 tenancy, we can begin writing the PowerShell script that will be resetting the user’s password.

For demo purposes, I have written this script directly into the browser and tested with the testing panel, which proves a little slow and clunky at times, but overall an okay way to test.

When creating Azure Automation scripts that are to include parameters to be provided from other applications, I find it best to start by adding in these parameters as the first things to write.

As I am looking to reset a user’s password, I want to pass the user’s email, so I will be setting up a string variable named $UserEmail – pay particular attention to this parameter name as it will be required in Flow to pass the parameter to Azure Automation.

         [Parameter (Mandatory= $false)
         [String] $UserEmail = "",

Once you have added your parameter it’s time to add the authentication details to connect to your Office 365 tenancy. In this example I’m doing this in two small lines of code.

 $creds = Get-AutomationPSCredential -Name 'MyDemoTenant’

Note: the name ‘MyDemoTenant’ is the friendly name created when you first added your Office 365 credentials above; this adds the credentials to a secure variable that we can use to connect to Office 365.

 Connect-MsolService -Credential $creds

If you happen to jump ahead and are testing as you go, you will most likely find that you cannot access and pass the parameters through Microsoft Flow to Azure as intended. I find that the parameters are not available either for consumption in Azure Automation or transmitting to Microsoft Flow until both the Azure runbook and a version of the Flow is published. This could be a bug and something soon to be ironed out, but it did require me to publish both before I could work with the parameters.

TIP: You may need to publish your runbook and Flow to access the parameters.

Now that the script is written and ready to go, let’s head over to Flow and provision a new personal Flow.

Login to Flow from:

Click Create new Flow > Create from Blank.

Now that a new Flow has been provisioned we can begin to configure our Flow.

As I am intending to reset a user’s password, I have selected ‘Flow button for mobile’ which will be used to pass on the user email address on the user account’s password to be reset.


Select the trigger ‘Flow button for mobile – Manually trigger a flow’

Once you’ve added the manual trigger action you will need to give the input a name and description; in this example I will be using UserEmail as the input name.

Now that the trigger is added, it’s time to add an action. In this example i’ll be using the Azure Automation (Create Job) action which allows me to fill out start my ‘ResetUserPassword’ runbook created earlier  and pass on the UserEmail parameter

So, we now have all the components we need to start wiring everything up!

As the Azure Automation action is added, you will need to logon with an account to your Azure tenancy. This can be the Azure tenancy connected with your Office 365 account or separate, it’s entirely up to you.

Fill out the details for the Subscription, Resource Group, Automation Account & Runbook Name.

The bit we are paying attention to is the Runbook Parameter that is now available to us: ‘UserEmail’. This becomes available once we have selected the RunBook name and it has recognised that the Runbook is requiring a parameter.

Select inside of the parameter input field and you will see that a whole range of options become available on the right hand side of the page. Select as the input name the name you created as part of the ‘Flow button for mobile – Manually trigger a flow’ trigger that you created.

IMPORTANT – I’m not sure if this is a bug while the Azure Automation action is in preview, but to get this working I did need to publish the Azure Automation PowerShell script first so that the parameter was available for consumption.

So now we have the parameter (user email address) executing and passing to our runbook, it’s time to finish off the script by adding in the Office 365 PowerShell goodness.

 [Parameter (Mandatory= $false)]
 [String] $UserEmail = ""

Write-Output "connecting to the demo tenant"
$creds = Get-AutomationPSCredential -Name 'MyDemoTenant'
Connect-MsolService -Credential $creds

#Resets the user password to Password1 temporarily, but is forced to reset the password on next logon
Set-MsolUserPassword -UserPrincipalName $UserEmail -NewPassword "Password1" -ForceChangePassword $true

So, now that both our flow & azure runbook’s are published it’s time to give it a go. I’ve installed the Flow app on my mobile, and as you can see there’s an awesome interface to start a new manually executed flow.


How easy is that!!!! If you have any questions please leave a comment.

Until next time.

See another one of our recent posts about – Azure Automation – What it is? Why should I use it?