I have a series of outlook rules which I need to automatically update for a group of people weekly. I know I can export them and import them, but I'm looking for somewhere to define them and deploy them in some kind of script of code.
Any ideas appreciated.
You have (3) options to manage mailbox rules:
Outlook Plugin supports most common rules. (client or server rules)
Exchange Management Shell (server-side rules only)
EWS Managed API (server-side rules only)
Related
We want to build a 3rd party plug-in to assess inbound and outbound messages according to certain criteria. Then we want to either change the message metadata or forward it, if it meets a particular criteria. It cannot be done with regexes or keywords. It is really a custom set of actions.
I found several leads, but it is not clear whether it can be achieved. Here are the leads:
https://learn.microsoft.com/en-us/previous-versions/office/office-365-api/api/version-2.0/mail-rest-operations#GetMessages - Outlook API is being deprecated but it seems that Graph API is taking over the functionality.
Exchange Web Services (EWS): https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-access-email-as-a-delegate-by-using-ews-in-exchange - but it's unclear whether our service can access user's messages with administrative privileges.
Exchange Online Protection: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/exchange-online-protection-overview?view=o365-worldwide - but is there a plug-in architecture?
Built-in content filtering: https://learn.microsoft.com/en-us/exchange/antispam-and-antimalware/antispam-protection/content-filtering?view=exchserver-2019 - again, is there a way to embed a plug-in?
Finally, transport agents: https://learn.microsoft.com/en-us/exchange/mail-flow/transport-agents/transport-agents?view=exchserver-2019 - that seems to be just the ticket, but I wonder if there's a catch?
Dear Exchange gurus, what the advantages and the disadvantages of every approach?
i'm quite new to Logic Apps. I got the task to make an auto reply function within Logic Apps that integrates with Exchange Online. Now I already performed this task using Outlook, but I have to be able to apply it to multiple mailboxes or even the entire company using Exchange. I'm about to get access to the Exchange Admin Center soon, but I don't really know how to start due to the fact that there is no simple way to make a connection to Exchange using Logic Apps. After some research, I think it's necessary for me to somehow make use of a REST API (I also read about the use of Exchange Web Services) to get the information I need, but my knowledge about this is quite small. I guess I'm gonna have to use a program like Postman to request information, so that I can start creating Custom Connectors to Exchange. If anybody has some understanding about this, feel free to reply and help me out! I will forever be gratefull!
There are several different approaches you could take to this if you (or probably they in your case) want your logic app to do all the work then you should use the Graph API rather then EWS (while its possible because its older API you'll loose marks on your assignment) have a look at http://martink.me/articles/using-microsoft-graph-in-logic-apps which covers the basics of what to do. To Get access to mailboxes tenant wide then you need to assigned Application Permission and get certificate (and store that in the KeyVault on Azure etc).
You can do this using Inbox Rules https://learn.microsoft.com/en-us/graph/api/mailfolder-post-messagerules?view=graph-rest-1.0&tabs=http and the Exchange Server will do all the work when it comes to doing the Auto-response (and has loop detection logic already) and your logic app then just need to do the Creation and management of the Rules.
But I would suggest you clarify with the person who assigned you the task whether they want the logic app to do the response (eg using the Graph API) or if its okay for the Exchange Server to do this for then (which should be more reliable).
You can also create Rules via the Exchange Admin Center and you could probably also through in Power Automate into the mix to do Autoresponse's so I'd clarify what they want so you don't waste time building something they don't want.
Looking for information on how to integrate VSTS to Office365: Outlook. Essentially looking for a method whereby a team member that does a great amount of fix-it tickets can drop them into the Azure DevOps Project from Outlook as many of those tickets get passed to her from users through email.
A right click >> add new task from Outlook to Azure DevOps would be ideal.
There is no built-in feature, but you can work miracles with Microsoft Flow, basically, the If This Then That from Microsoft. it comes with built-in tasks to trigger on Outlook/Office 365. Moving an email to a specific folder or tagging it with a specific tag would be enough for Flow to trigger a rule.
This template rule uses the "When an email is tagged" and this template rule creates a Bug work item based on a trigger. Combining these two should let you achieve what you're looking for.
If you want integration in the Outlook Windows client, then there are a couple of commercial options available: There are a couple of add-ins for Outlook. Team Companion, TeamLook and TFS Work Item from Outlook spring to mind.
An alternative option is to use an Azure Function which is triggered by Azure DevOps Service Hooks. Not sure if you can bind an Azure Function to an Office 365 mailbox. Flow could act as an intermediary here as well.
You might want to check this tool called TMO that will enable you to create and manage work items from Outlook. It also allows you to automatically create work items in Outlook using a rule based engine called Auto Pilot
I had the same issue and just downloaded the TMO tool, and it works great. It does what I expected, once I figured out how to find the URL to connect to my Azure Dev Ops (ADO) server. Note: ADO is the new name for TFS or VSTS.
There's also a PowerAutomate called Create an Azure DevOps work item when email arrives with 'Bug' in subject that does just what it says. If that doesn't work for you, try modifying this one or creating your own.
Linda
How can teams located in different locations can work on the same NiFi dataflow at the same or different time?And how do we move each "only changes" in Dataflow to QA & UAT environments ?
Generally the approach is to organize the top-level canvas into process groups for each team that will be working on something. Then you can apply security policies to ensure that each group can only modify their respective process groups.
This post shows an example of how to secure an instance and setup policies for processor groups: https://bryanbende.com/development/2016/08/17/apache-nifi-1-0-0-authorization-and-multi-tenancy
Deploying flows between environments is an area currently being worked on by the community.
There is a feature proposal here that describes some of the planned capabilities: https://cwiki.apache.org/confluence/display/NIFI/Configuration+Management+of+Flows
There is a sub-project of NiFi called the registry which is where the work is being done:
https://nifi.apache.org/registry.html
Currently your options would be to export a template of a process group and import it into another environment. You could script a lot of this by using the REST API. Anything you can do from the UI can be done through the REST API which is easy to see by opening something like Chrome Dev tools and watching the requests being made while using the UI.
Is there any way through which I can exchange data between two organization.
I want to do my coding in Plugin only. Can we write a code in plugin by which it accesses/manipulates the data of a different org through web services only and not directly hitting its database.
In know the orgs are different worker groups. Just wanted to know if its possible or if there is any other technique.
Thanks in advance.
The data for each CRM organisation is exposed via web services which differ slightly for CRM 2011 and CRM 4. The best thing to do is download the latest version of the SDK for the target platform as there are several examples in there for plugins and service based operations.
From your plugin you will be able to access the other organisation via this service and a connection to the service for the "local organisation in which the plugin is running will be available from the IExecutionContext parameter passed to your plugin. Any operations you carry out across both orgs will not be transactional though.
Also be sure to take a look at the sync and async options available for the plugins. If their use is appropriate for your scenario consider using an async plugin for the updates to the target org to minimise their effect on the source org.
Plug-ins will work. Hitting the database directly is actually not a supported model anyways. You can also think of using BizTalk as the middleware.