An artefact of the way that IT operations have evolved over the last 20 years is the idea of two-speed IT. Using this, the IT department is seen as not only a key enabler to adopt change but also a hindrance due to the speed at which they are able to execute. This has led to departmental decision makers using their own purchasing power to deliver the solutions required in a timeframe that is acceptable.
This notion of two speeds usually results in the IT department having to accept responsibility for purchasing decisions they did not make, or worse leaving it to departmental workers taking on the responsibility for IT delivery.
This approach does not provide a good outcome for the business as it pushes responsibility away from the IT department and a reliance on potentially unskilled personnel.
The business should be doing what the business does well, and the IT department should be responsible for enabling the business to achieve its outcomes without getting in the way.
Microsoft InfoPath was part of the Office suite that started this journey. By consuming XML web services and presenting forms-based access to data, it put the development of departmental solutions in to the hands of the people who knew and understood their processes, while leaving the IT department to manage the physical data access through the provision of the services. In the great vision of SOA, this type of solution showed real promise for business productivity improvement and transformation.
After InfoPath came Microsoft LightSwitch as a means to replace, or at least modernize departmental application access, particularly siloed data and simple workflow locked up in Microsoft Access databases. Microsoft Access, while useful for delivering quick solutions into the hands of the people who needed them, also creates a situation where there may be many instances of data and processes that govern that data can easily become decentralized.
Neither InfoPath nor LightSwitch truly delivered on the promises and expectations they were supposed to deliver.
As technology has moved forward, either with the ubiquity of APIs or varied data source types, such as NoSQL databases or data stored in Software as a Service solution, the requirements to drive business productivity through the use of these sources has grown. With that has come the need to connect to disparate endpoints and make sense of the data in a meaningful way to the business.
This need has introduced the concept of citizen integrators, business people who need and have the tools in their armory for building the business applications they require that are connected to the data sources and services that define and govern their business processes.
To solve this problem, Microsoft has introduced PowerApps and Flow.
PowerApps is part of Office 365, although can be purchased separately, and provides a simple way to build powerful business applications by bringing in data from multiple sources. Data sources are made available using connections that are used to build forms-based applications that support not only standard create, read, update, and delete functionality, but also complex search and field validation. Since the service leverages the Logic Apps service, it provides a range of connectors out of box, including Office 365, Dynamics 365, Dropbox, Azure services, and social networks.
In this way, it is similar to both InfoPath and LightSwitch, but is much simpler and intended to be a tool that can target business users. Furthermore, applications built in PowerApps work immediately on tablets and phones to help deliver a truly digital experience quickly and easily.
An important aspect of any data processing is ensuring that the data structures used should be compliant to corporate rules and have a governance structure around them that ensures that proliferation of disparate types is avoided. This is akin to master data management, and Microsoft has introduced the Common Data Services, which includes the Common Data Model, to provide this structure and governance. For more information on these, see https://docs.microsoft.com/en-us/common-data-service/entity-reference/introduction.
As an example, let us introduce a scenario. In our scenario, our fictitious company Sunny Electricals wants to provide a process whereby new customers can call a helpdesk and request a change to their credit limit. For this, a customer service representative needs to be able to retrieve the customer details and update their credit limit as required. The responsibility for providing access to this data is the IT department, but they should not be concerned with the process of checking the limit.
For our scenario, we will keep things simple and use a basic database table, but this table exists in a SQL Server database that exists on premises:
CREATE TABLE [dbo].[CustomerCredit]( [CustomerId] [int] IDENTITY(1,1) NOT NULL, [CustomerName] [varchar](255) NOT NULL, [CustomerContact] [varchar](255) NOT NULL, [CustomerEmail] [varchar](255) NOT NULL, [CustomerCreditLimit] [float] NOT NULL, CONSTRAINT [PK_CustomerCredit] PRIMARY KEY CLUSTERED ( [CustomerId] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]
PowerApps is accessed by going to: https://powerapps.microsoft.com/en-us/. Once signed in, you can view any applications that have been built and can add or use connections that have been created.
In our scenario, we wish to connect to an on-premises database containing the basic information about our customers and their credit limit.
Clicking on Install a gateway downloads a small application that creates a Service Bus relay between your on-premises data source and PowerApps. When the installation is complete, you are prompted to sign in with an organization account that should match your PowerApps account. You can then configure the data gateway as required.
Clicking on Configure finishes the installation of the gateway, and if the connection is made successfully, you should see the following:
The gateway connection can be checked in the PowerApps portal and should have a status of live. At this point, we have a tunnel between our PowerApps solution and the machine hosting the gateway but we have not yet created a connection. To create a connection, we go to Connections and click on +New connection.
We search for SQL Server, since our on-premises data source is a SQL Server database, and we need to make sure that we choose to use our newly installed on-premises gateway.
Once the details are entered, clicking on Create creates the connection. Once completed, the connection should show a status of connected in the PowerApps portal.
To provide this connection to others, for instance, if this connection had been created by an IT administrator and they wanted to make it generally available, the connection can be shared. Within a connections details, clicking on Share allows this sharing to be configured. For example, the connection can be shared with the entire organization within Office 365.
It is now time to create our simple PowerApp that allows updating of the information contained within the database. To create a PowerApp, you can use an application that can be installed from the Store or the PowerApps portal. Alternatively, at the time of writing, a web application creation experience is available in preview. Clicking on +New app in the PowerApps portal starts the process.
When the PowerApps application has opened, clicking on New allows the selection of the connection to be used to access the data. A list of standard connections is available to configure, or clicking on the right arrow allows selection of a custom connection.
In our case, we want to connect to the CustomerCredit table we previously created, so we can view and update the information as required. Clicking on Connect completes the connection to the data source.
PowerApps connects to the data source and builds a very basic application that allows you to immediately be productive. By default, the application that is created has browse (including Search), detail, and edit views that contain all the information from the data source. Clicking on the play icon allows the application to be previewed.
The application can be tailored to meet the specific needs of the people that need to use it. For example, layouts can be changed, along with colors; new screens and new data sources can be added. On the edit screen, validation is applied based on the incoming data requirements.
Validation and layout are locked by default for incoming data fields, but can be amended by clicking the padlock icon to unlock the field in the right hard dialog.
Most controls support a range of properties that define their layout and text, but they also support actions that can be tailored to provide, for example, the navigation or initiation of Flows. On the edit screen of our basic application, which contains a form named EditForm1 and which posts the data back to the database, the confirmation icon has an action SubmitForm(EditForm1). This submits the form to PowerApps, which understands that this action needs to post the data back to the database.
Once all updates have been applied, the application is previewed by clicking on the play icon. The emulator provides full control over both the screen flow and data, thereby providing a good mechanism to test the application, any validation applied, and the general flow and storage of data.
Once the application has been completed, it can be saved back to PowerApps, which then allows it to be used and shared by others.
Once saved the application can be shared or amended as required, either back in the Windows 10 PowerApps application or online. The application can also be played, and now accessed from a mobile device that has the PowerApps application installed, available for Windows Phone, iOS, and Android.
With this simple scenario, we have shown how easy it is to start creating applications that can deliver real business value quickly to the people who need them. By creating connections to data sources and sharing them across an organization or to individual users, business people that have access to PowerApps can create applications that meet their needs and demands to help boost their individual productivity.
To extend the use of PowerApps further, Microsoft Flow can be used to provide an experience similar to IFTTT (http://www.ifttt.com).
Although PowerApps provides an opportunity for business professionals to build just in time applications that expose their data sources in a meaningful way, it is still necessary to create governance and control over the flow and orchestration of that information. This is where Microsoft Flow play its part.
Microsoft Flow is a simple workflow engine that allows a sequence of events to be stitched together to create an integration solution that can combine inputs and outputs from several sources to help extend the reach of basic PowerApps applications.
In this way, Microsoft Flow helps to deliver the power of integration and orchestration to PowerApps to supercharge productivity even further.
To illustrate this, let us take our previous scenario and extend it. In the new scenario, when a customer service representative looks at increasing the credit limit, an approval process is performed and then the customer is e-mailed to let them know the result of their request and the database is updated to reflect this approval.
For the customer service representative to be able to have self-service to create this business process workflow, connections to external business services need to be set up and configured.
First, we need to create a new flow, and to do this, we go to the Flow portal. The portal can be accessed directly or via a link in either the PowerApps portal or the PowerApps designer. The Flow portal can be accessed via https://flow.microsoft.com/. If accessing via the PowerApps portal, you can choose to either create a new flow from blank or choose from a template. Accessing via the PowerApps portal and choosing template is a great way to get started as the list of templates shown are limited to only those that support PowerApps.
There are many templates to choose from that represent common tasks; for our scenario, we wish to have an approval process for when a credit limit change is requested.
When we select the template, we need to provide some credentials for Office 365 as this is being used to deliver the e-mails. Like Logic Apps, on which Microsoft Flow is based, any credentials provided for a connection are stored securely. Once the template has loaded, we can see that we have a PowerApps trigger that then sends an e-mail. This e-mail contains options for approval or rejection, and a condition then sends an e-mail containing the outcome of the decision.
If we expand the e-mail controls, we can update them as required. One option that is available to us in the designer, is the ability to Ask in PowerApps. When we choose this option, a variable is created, and we can then provide the information directly from within PowerApps as part of an action. This means that we can pass information from our executing PowerApp directly to a new instance of a Microsoft Flow, making that instance contextually aware of the state of the PowerApp.
In our case, we will choose the e-mail addresses we want to send notifications to. In the previous scenario, we used the basic application to handle all communication to and from the database. This included using the default behavior on our edit screen that simply submitted changes back to the database. In our new application, there is a process that interrupts this transaction, waiting for an approval process, so we need to commit the changes to our database directly. We can do this using a SQL Server Update Row shape within our flow. Since the Microsoft Flow is still within the context of PowerApps, we can choose any table that is connected via a SQL connection, which is our case is our CustomerCredit table.
Once the designer has loaded, we have a list of the fields from the table and can again choose to Ask in PowerApps , so we can provide the information in the PowerApps designer when we update the appropriate action.
Once we have updated e-mail addresses and some e-mail content, and added our SQL Server update, we can create the flow so that it can be used in our application.
The Flow now appears in the PowerApps portal where it can be enabled and disabled, deleted or updated, which launches the Flow portal again. To make use of the flow, we need to go back to the PowerApps designer and update our previous application.
First, we add a new screen that will be the page to which the application will proceed once we have submitted our credit limit change request. This is just to provide some information to the user, we could equally navigate back to the browse screen.
In the previous scenario, we accepted all the default behavior to quickly demonstrate the power of PowerApps. However, for our second scenario, things are more complex, and we need to update the default behavior and added new functionality based on our newly created Flow. In the example of our Processing screen above, we update the OnSelect action of the button to navigate back to the browse screen by setting the OnSelect action to Navigate(BrowseScreen1,ScreenTransition.None).
On our browse screen, we need to update the navigation that takes the user to the details screen to reload the data from the database to ensure that the details are always up to date. We do this by setting the OnSelect action to Refresh('[dbo].[CustomerCredit]');Navigate(DetailScreen1, ScreenTransition.None). This shows the ability to combine commands using a semicolon, and in this case, we are refreshing our data source and then navigating to the details screen.
Once we have done some simple changes to the layout, added a new screen, and changed some of the navigation, we then need to update what happens when we click on the confirmation button on our edit screen. Previously, this button submitted the form, but now, we need to initiate our instance of our flow. Before changing this, we need to be able to determine CustomerId of the record that is being edited. To do this, we simply add a new data card for the CustomerId data field. In our case, we set this to be hidden, so we can access the text of the field without it displaying. Once this is done, we can choose our button and go to Action in the ribbon and select Flows. This displays a list of flows that are currently available as well as offering an opportunity to create a new one.
We chose to Ask in PowerApps when we created the Flow, so when we set the formula for the OnSelect action, we need to provide the values that will be passed to the Flow instance. The formula takes the form [FlowName].Run([Parameter List]). The parameter list is based on the values chosen as dynamic data within the Flow. For our case, we have e-mail addresses that we are sending e-mails to, and data values from our data source that we are using to update the record using our SQL Server connection. The expression used is as follows:
Sendapprovalemailandfollowupviaemail.Run("[ApproverEmailAddress]",DataCardValue7.Text,DataCardValue9.Text,DataCardValue8.Text,DataCardValue5.Text,DataCardValue7.Text,DataCardValue6.Text);Navigate(Screen1,ScreenTransition.None)
As can be seen, we use the values of the text fields taken from our edit form. The last part of the expression navigates to our screen that displays the helpful message about processing.
Once we save the application, we can test it using either a mobile device or the Windows 10 application. First, we update our credit limit, in our scenario, raising the limit to $17,000, and click on the accept button. This takes us to our Processing screen from which we can only navigate back to the browse screen.
When we check our Office 365 mail, we see that we have received an e-mail asking us to approve or reject the increase.
Clicking on Approve sends another e-mail to the person requesting the increase.
We can then either check our data source or look in the PowerApps application at the details for the record we have updated.
We can see that our Flow has run and completed. If we go to the PowerApps portal, we can go navigate to our flow and check the run history. To check the history, we click on the information button.
We then get a list of runs and their status, and we can filter the list to see specific types of runs.
Clicking on a run allows us to view the Flow run and examine the details.
Clicking on any of the components opens up information about the inputs and outputs, and clicking on the PowerApps component shows the values that we passed out of the PowerApp to the flow instance.
In this scenario, we have shown how to integrate a simple orchestration workflow for approval and database update in the context of our fictitious company. However, Microsoft Flow has capabilities beyond just PowerApps and has connections and templates available for building a range of other interactions.
Microsoft Flow provides a first-class experience to create simple or complex workflows that are simpler to design than through the full Logic App design experience. By removing the need to look at a code view, integration is put in the hands of the citizen integrator, and when combined with PowerApps provides a great experience for creating business productivity applications that meet the specific needs of the individual.
The integration community is truly global and enriched by the people who contribute toward it. With the pace of change being as quick as it is, it can sometimes be a little daunting to keep up with things.
This is where the community plays a huge part. Through the Microsoft MVP program and the dedication of bloggers, the time between feature release and documentation or review is now shorter than ever.
As a reader of this book, you would be encouraged to take the contents, build on them, deliver solutions for the organizations for which you work, and play that knowledge and experience forward through blog articles or TechNet Wiki articles (see: https://social.technet.microsoft.com/wiki/).
Conferences and industry shows are another great opportunity to interact with the community of professionals, and one of the strengths of the Microsoft integration community is its openness and willingness to help.
Leveraging the community is a great way to stay current, but the strength of the community is in people getting involved; a community should grow and evolve to embrace the new technologies being released and the people willing to contribute to the body of knowledge held by it.