New white paper – “Transforming business process with Microsoft 365”

[Chris McNulty]

White Paper

Microsoft 365 provides innovative capabilities to empower anyone - developers, power users, and information workers - to craft business applications tailored to real-world needs.  

SharePoint lists provide foundational data storage across the suite. PowerApps and Microsoft Flow bring custom forms and workflow into business applications. And Microsoft Forms and Power BI extend business apps with data gathering and analytics.

That’s a lot of power.  If you’re a problem solver, you’re in the right place.  Our new white paper “Transforming Business Process with Microsoft 365” helps you understand these capabilities.  You'll learn about why business apps matter.  We review the core capabilities of each tool – SharePoint lists, PowerApps, Flow, Forms, and Power BI.  Finally, we complete the journey by presenting three scenarios to guide your implementation:

• Event organizer
• Travel approval
• Employee onboarding

Each solution is accompanied by templates you can use immediately.  Download the white paper today to start this journey.

Solutions

We also know that there's no substitute for learning by doing. That’s why our white paper is accompanied by three downloadable scenario templates.  Each includes setup scripts, PowerApps, Flow, and other tools, along with videos and step by step instructions to help you bring each of these solutions to life in your own environment.

These solutions take their place alongside the other templates already published on the TechCommunity Resource Center.  Let's take a look.

 

Event organizer

This solution allows you to invitee attendees to self-register for an event using Microsoft Forms.  Registrations are tracked in a SharePoint list, which can be deployed automatically using our site scripts included in the solution. Microsoft Flow is used to provide alerts , confirmations, and reminders about the event to attendees and staff.  Power BI is used for real-time reporting on attendee registrations and attendance.  Finally, this solution includes mobile and tablet versions of our PowerApps solution for checking in and managing attendees on the day of the event. Download the template and get started.

Event Organizer

Travel Approval

Travel is a critical part of business operations. This solution allows employees to easily submit travel requests from desktop or mobile devices using PowerApps. Requests are automatically routed using Flow to the appropriate manager and travel department for approval.  Managers can also access Power BI based status reports for all travel requests to verify current status and manage budgets.  Get started with our downloadable template.

Travel Requests

Employee onboarding

The Employee Onboarding app is designed to streamline and simplify the process of bringing a new employee onboard into the organization. In many organizations, onboarding new employees can be a complicated and laborious process.   This solution integrates PowerApps, SharePoint and Flow to manage procurement, logins, email and training tasks for new staff.  Download our template to get started today.

Employee Onboarding

Conclusion

Business apps are essential to transforming processes in every organization's journey to digital transformation.  Our new white paper and templates provide a road map for learning and adopting these solutions in your organization. We look forward to learning more about your experience here on the TechCommunity.  

[Rachel Davis]

@Chris McNulty Again, I raise the same concern with Flow. Do we really think it's a good idea to tie business process automation to the credentials of an individual user rather than to the site or list? Yes, we can share a Flow, but even a shared Flow is still tied to the credentials of a SINGLE user.  Life happens. People change jobs, go on maternity leave, or get sick or even die suddenly. The potential for interruption to the business is massive, especially when we're talking about onboarding or travel approval. 

You market Flow towards end users but it creates a massive risk for interruption to the business. When you add in the fact that many departments run everything through their local power user, we've magnified that risk exponentially. Now it's not just one or two Flows that will go down, it's the entire department.

What are the plans/recommendations from Microsoft to address this risk? This is the one thing that is keeping us tied to SharePoint Designer workflows. They won't die if the user does.

[Chris McNulty]

Thanks for sharing.  Yes, we think Flow is the right home for business process - more features and integrations than legacy SPD, which was deprecated five years ago.

Regarding Flow ownership, we introduced list/library ownership last year - you can assign a list or library as owner of a Flow (we do this automatically for system templates liek page approvals)  You can also add a group as owner.

[Malene Friborg]

Hi @Chris McNulty ,

I share the concerns of @Rachel Davis  In regards to this. So, I have some questions.

I love flow and have done a lot (or around 20) and put them into production. On all of them I have added other owners since I want the flows to be accessible if I leave the company. My assumption is that the other owners will open the flows and edit them re-creating the parts of the flows that use my connections, thus securing that the flows can start running again if my account (and its connections) is removed or disabled. I have this marked as a manual process. I don’t like it, but I want to use Flow so I just accepted that we would need this manual part if I leave.

Would it be possible to change the ownership of the flows to a Group and automatically have the flow use another connection (a person from the group) if my account is gone?

Or same thing if I change the ownership to a list or library… will I get a new connection (one that is not mine) doing that?

Thanks in advance :smiling_face_with_smiling_eyes:

Best regards,

Malene

[Rachel Davis]

Thanks for the reply, Chris. I read this article on Flow ownership by list/library owners and tested it out on a Flow. If I understand correctly, this gives any list owner the ability to edit the Flow - which is great. Really. But it still doesn't solve the problem that the Flow itself is logged in to SharePoint using my credentials. If something happens to me and my credentials, what will happen to the Flow? Will it continue to run uninterrupted? Or will it stop until one of the other owners edits it to use their credentials? 

I totally agree that Flow is a much better tool than the SPD workflows in every way except this one. This gap is a grave risk to business continuity and one that is not adequately explained/disclosed to the users. 

[Scott Oxendine]

Our production flows are created and owned by service accounts. Connections within the flows are made with the service account as well. Then, the flow is shared to the group the administers the flows.

[Fernando Melo]

I too have made it a habit to use service accounts for flow. However, this does present a rather interesting bottleneck. Who gets access to the service accounts to create the flows?
What do you think of these options:

1. Create a Flow Group/Team/Site- The Service account will have full control of the site and or lists. Users can creat flows but then must share the flow so that the service account can take ownership. I wonder if there is a flow for this? Perhaps there could be a flow function to automatically give flow ownership to a list/library/powerapp if it detects the author account is changed

2. In an enterprise use something like secret server to gain access to credentials of the service account. this way you can create the flow using those credentials. 

Are any of these possible?

[Rachel Davis]

We have 22,000 employees globally. IT is not going to give random humans access to a service account. 

The biggest issue I have is that all the material for Flow is totally geared towards "citizen developers" and business users for business processes automation. Read the whitepaper in Chris' original post. To paraphrase, "Citizen developers can use these business apps to automate processes like on-boarding and travel approvals". Makes it sound so easy, anyone can do it. And they do. 

None of this material comes with a SINGLE WORD OF WARNING that the process could come to a grinding halt if there is the smallest problem with the credentials of a single user. And last I heard, if a Flow stops running due to problems with credentials, there is NO WARNING to the user, other owners, etc. 

This is a massive risk to business continuity that no one mentions. 

[Scott Oxendine]

I don't see it as random access to a service account. The flow actions utilize connections under the service account. The flow itself would be shared to a group for its management and maintenance. No one from that group even has to know the password of the service account once the connections are created.

I think the way Flow allows for modifying the connections an action uses is the least risky way to do automation. It only acts under the credential the author specifies at any given step.

[Fernando Melo]

Right so its like an impersination step.

But I think that Rachel has a valid point. In order to use the service account credentials to make the connection, one must first create the flow with those credentials right?

Unless there is a way to create a template of that initial flow. Is there? This way you can start with a pre made template using the other credentials and continue with yours?

[geraint james]

It's a classic catch-22. Citizen developers can create their Flow's and while the person who built it remains in the company and/or the scope of their use is within a team, then if they do have a problem with credentials, then the impact is small and probably acceptable.  But, as soon as you try to scale to a larger number of users or build recurring flows, then that's when the need for a service account seems to manifest itself.

But, many companies are struggling to understand all the products in Office 365 and the governance needed to administer and safeguard them all effectively. So, in my experience there is a real concern around enabling Flow (and PowerApps) licenses for the people who can best prove their value.

If you then add the need for a service account into the mix, especially post-GDPR, then what started out as a simple productivity solution becomes an exercise in frustration. Theoretically the Flow could be exported by the citizen developer, imported using the service account, and then re-configured with new connections. This is all easily done, but it's very hard getting any of this to happen without high-level support for it.

[Rachel Davis]

I would have way less of an issue with the situation if the limitations were clearly communicated to the users, like "Hey, this is an awesome tool that is super easy to use. Be aware of this thing and here are some best practices around protecting your process in the event something happens to your or your credentials." Then if something happens, it's a case of "You were warned".

But I can't find a thing in the documentation or this paper or anything the Microsoft puts out about Flow. And I can't educate every user who has access to Google and the Flow button. To the best of my knowledge we haven't had anything major fail yet, but I have a sneaking suspicion it's only a matter of time. 

[geraint james]

I couldn't agree more, and if the guidance is weak in that area, what about the implications regarding the data!? Hopefully we're all using DLP policies and are busy familiarising ourselves with the new PowerApps/Flow audit events that have just become available in the O365 Security & Compliance centre

[Darrell-Johnson-Dental]

Just my two cents.  I think there's some misunderstanding in the comments how Flow works.  It's best practice to share important flows with one or more backup owners.  If there are problems with the Flow, including user credentials or connections, in my experience Flow will auto-notify the other owners, who should be trained how to correct connection issues by editing the Flow and taking ownership of the connections.

[Rachel Davis]

Flow will notify you if there is an error in the syntax of your Flow. It does NOT send an email that a credentials issue is preventing it from running at all. 

Example: I had a Flow monitoring my Twitter feed and sending certain # to a SharePoint list. I changed my Twitter password forgot to update Flow. No message, no nothing. The Flow entries just stopped. Today I went into Flow to find that I had "Connection issues" with O365. Not sure why, but I hit the fix button and now it's OK. Great, but there was no notification that the connection had broken in the first place. 

So now let's imagine this was a business process in a global company like mine. I'm in US Central. If Flow goes down during APAC business hours, then what happens? They just sit and wait for dawn in the US? How is that acceptable?

Again, my biggest issue here is that this risk is NOT presented to users by Microsoft.

[Heiko Fuhrmann]

same situation here with 120lk employees Flow,Powerapps enabled, no way, solution  for critical business apps and "run as" option. Service account only an option if IT  does own the password, on top the send e-mail limitation where you also need a service account, no solution for "sender user friendly dummy address".

[Rachel Davis]

PowerApps are fine. I find it annoying to work in, but not a problem. We are working on a process to bridge the gap between the "citizen developer" and IT. The vision is that users can create their Flow to their specifications, then submit a ticket to have it transferred to the service account. Haven't worked out all the kinks - like what happens if they need to update it? We can't let them have access to the service account version, so is that another IT ticket? Ick. Do we let them keep a turned off copy as "theirs" so they can make changes and resubmit? What are other people doing about this?