https://docs.microsoft.com/archive/blogs/artdb/feed.xml 354 Send data. End with CRLF.CRLF Wed, 17 Apr 2019 03:44:30 GMT en-US hourly 1 https://docs.microsoft.com/archive/blogs/artdb/using-microsoft-flow-to-curate-social-media-data Mon, 25 Sep 2017 02:00:17 GMT https://blogs.technet.microsoft.com/artdb/?p=165 Email yourself new Tweets about a certain keyword template after a quick search for Twitter in the Social Media category. Flow needs to connect to Twitter and Outlook.com Services as the source and destination of data within the flow. The template contains the basic building blocks of a flow. Each flow contains a combination of triggers, actions, conditions, and loops.

• Triggers are events that start a flow.
• Actions are tasks accomplished by the flow.
• Conditions allow for branching if/then logic in a flow.
• Loops are for iterating over actions more than once.

Every flow starts with a trigger. In this scenario, the trigger is any tweet that contains specific keywords. Once the tweets have been collected, I want to gather some information about the Twitter users. I used an action to get the usernames and follower counts. Then I added a condition to cull my results to only users that have greater than 500 followers. Next I added another action to send an email to my email address. The nice thing about the Send Email action is that the criteria for the email body and subject are predefined. The only required change was to add my email address in the To field. I also added "#twt" to the Subject field. This gave me a unique identifier I could use in my Outlook rule to automatically move these emails to a specific folder. I added one additional action: a push notification. This allows me to get a notification on my phone each time this flow delivers an email to my mailbox. You must have the Flow app* installed on your mobile device for the push notifications to work. In addition to providing push notifications, the Flow app has much of the same functionality as the web portal. This scenario demonstrates "the art of the possible" with Microsoft Flow. As an IT professional, I am using it as a tool to enable me to remain current with the latest industry news. However, this only scratches the surface of how you can use Flow to automate business processes - approval workflows, dissemination of sales leads, collection of data to be stored in the cloud or on-premises, and much more. Microsoft Flow is part of a powerful and adaptable business application platform that includes PowerApps, the Common Data Service, Dynamics 365, and Office 365. You can check out the Guided Learning section of the Flow site to gain a deeper understanding of its capabilities or you can sign-up for free plan to begin building flows. *The Flow app is available for Android, iOS, and Windows Phone.]]> https://docs.microsoft.com/archive/blogs/artdb/administering-office-add-ins-within-exchange-2013-and-exchange-2016 Fri, 07 Oct 2016 19:08:28 GMT https://blogs.technet.microsoft.com/artdb/?p=35 Office Add-in Primer for Exchange Administrators Office Add-ins, formerly termed apps for Office, is a platform that allows developers to use web-based tools to build apps that are displayed within the Outlook Reading Pane or inspector window. This function is native to Exchange 2013 and Exchange 2016. As an Exchange administrator, you have granular control over its use within the environment. You can use the Exchange Management Shell (EMS) to display the relevant configuration settings. Get-OrganizationConfig | Format-List AppsForOfficeEnabled You will see that this functionality is enabled by default. Setting AppsForOfficeEnabled to $false will prevent new apps from being published by the user or Exchange administrator. The Get-App cmdlet is a quick and easy way to list all apps that are available within your Exchange environment. Get-App | Format-Table DisplayName,AppID,AppVersion,Enabled,DefaultStateForUser -Autosize All native apps are enabled by default; this means the Exchange server will advertise them to the Outlook client. Whether they are displayed or not is determined by the configuration of the add-in. Outlook will only activate a contextual add-in if the activation conditions are met. For example, the Suggested Meetings add-in will only activate when Outlook detects a message that includes a reference to an event or meeting. Let’s say I receive an e-mail from a colleague that includes the text, "I would like to meet with you tomorrow after 3PM".  This event would trigger the Suggested Meetings mail app to appear within the inspector window. Office Add-In Components Native apps are made available to your Exchange user community with no administrative effort, they just work! However, you can incorporate 3rd-party add-ins that extend the capability of messaging related applications. You can also publish add-ins that have been developed by your company's software development staff.  Add-ins that integrate with Outlook are referred to as mail apps. The basic components of an Office add-in are an XML manifest file and a webpage. The manifest defines the basic logic of the add-in and points to the webpage that implements the app UI and custom logic. The Exchange server is responsible for storing and advertising the manifest XML file for mail apps. The Get-App cmdlet displays the settings from the manifest XML file. A snippet of the Suggesting Meetings mail app manifest is included below. Get-App -Identity bc13b9d0-5ba2-446a-956b-c583bdc94d5e | FL DisplayName,Description,ManifestXML I’ve omitted sections of the manifest to make the data a little easier to read. The key takeaways are the cmdlet syntax and some of the data points, such as DisplayName, Permissions, and Rule configuration. A full description of the Office Add-ins XML manifest can be found at the Office Dev Center. The manifest only needs to be published once for your organization. The published XML data is stored in the SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} arbitration mailbox by default. Use the following cmdlet syntax to confirm your environment is using the default mailbox for storage of the manifests. Get-Mailbox -Arbitration | Where-Object {$_.PersistedCapabilities -like "OrganizationCapabilityClientExtensions"} | Format-List Name,PersistedCapabilities Hopefully this information helps with your understanding of how Exchange enables the advertisement of Office add-ins. Outlook 2013 and newer clients are programmed to automatically read the manifests on startup. As users view or compose items in Outlook, their operations are checked against the activation conditions of the mail app. Outlook displays the app when the conditions are met. Mail apps can also be set to mandatory, which means they are always displayed by the client. David Craig, Office PFE, recently published an article titled Developing an On-premises Web Add-in. I recommend bouncing over to his blog if you are interested in learning how to code Office apps for on-premises scenarios.]]>