This post extends what I wrote in a previous one about Try-Catch pattern in Microsoft Flow. In this writing I am focusing on how you can log errors that occurs in your Microsoft Flows in a single place, using Azure Application Insights.
The only trigger built-in in Microsoft Flow for Twitter is “When a new tweet is posted”. However, the list of events available in Twitter API account activity documentation is much wider, built of 19 options. But how to get to them?
Still being under impression from working with Azure Functions, I decided to try finally build a solution for Nintex Workflows for Office 365, where I have a single repository of workflows’ definitions, and from here I am able to publish them across the site, to different libraries or lists. Previously I was only able to do it using PowerShell or tools like Postman or Fiddler. However I wanted to have a single workflow that does all of the magic for me.
When you want to call methods or objects in C# code, you must declare them with “using” statement. But what if the package is not available? Then you must first make a reference to it. When programming in local environment it just require to upload needed dlls into the project. But what when you are not using desktop IDE, but through the Azure console?
Although it has been repeatedly said that the history of InfoPath is over, for many companies still building workflows’ forms using InfoPath is as obvious as using Excel. However, when doing that in Office 365 and SharePoint Online the product’s boundaries are really visible and are becoming a real pain.
I’ve been struggling some time ago with an issue related to the workflow’s instance size (here), what was directly related to the size of the InfoPath form together with attached files. The obvious solution I was thinking then was moving those attachments away from the form, into a dedicated SharePoint library, but I wasn’t able to do that easily mainly because of the algorithm that is used in InfoPath to handle file attachments.
It has already been announced couple of months ago, during the Nintex InspireX conference in New Orleans, in February this year, by Vadim Tabakam and Brad Orluk during their presentation “Extensibility on the Nintex Workflow Platform” and later on Nintex Blog.
The new, cool feature (that now is in beta preview), called “extensibility framework”. The tool that is allowing customers to add to the Nintex Workflow Cloud a custom REST API endpoints, that are “encapsulated” into ready-to-use actions. How does it work?