There are two type of workflow available in the mscrm dynamics. 1. Configurable workflow 2. Custom workflow.
My Question :
In which scenerio, we use the custom workflow ?
How custom workflow are different from plug ins ?
1) You must differentiate between "custom workflow step(=custom workflow activities)" and "Custom XAML workflows" (just for the sake of completeness):
You use a custom workflow activity (thats a custom workflow step written in c#) if non of the standard workflow steps fit your needs and you do not can use a plugin (see below). Custom workflow steps are especially helpful if they represent a generic functionality which can be reused.
You use a Custom XAML workflows if you want to use the full power of the windows workflow Foundation instead of the limit subset which the dynamics crm workflow designer provides. You must develop the Custom XAML workflows outside of crm (in visual studio for example) and then deploy it into crm. But beware: You cannot edit it inside crm and you cannot use Custom XAML workflows in the crm cloud (=crm online). You also have to enable Custom XAML workflows in the crm config database (they are disabled by default).
I would recommend against Custom XAML workflows, they are not very well supported/integrated into crm and they are error prone.. Use Plugins or a combination of custom workflow activities instead. Another option is to write a c# windows service which connects to crm and accomplish the desired functionality from outside.
2) It depends if you are using Dynamics 2011 or 2013/online. In 2011 Workflows are always asynchronous. They can be triggered automatically by a trigger (create entity for example) or manually by the user. In the first case they run under the userid of their respective owner, in the second case they run under the userid of the user which starts the workflow. Plugin can run synchronous or asynchronous and they are capable of doing user impersonation. But they cannot directly be triggered from the user. Workflows are suitable for long running stateful persistent background operations, Plugin for stateless short running operations.
If you are using crm dynamics 2013 then workflows can also run synchronous.
Only synchronous operations can present error messages to the user.
We have to use custom workflow actions when it is not enough standard workflow actions.
https://community.dynamics.com/crm/b/crmpowerobjects/archive/2013/05/28/comparison-using-workflows-vs-javascript-vs-plugins-in-dynamics-crm.aspx
Step by step creating custom work flow -
http://mahenderpal.wordpress.com/2012/08/26/step-by-step-creating-custom-workflow-in-microsoft-crm-2011/
It specifies a scenario also.
For around Dynamics crm follow -
http://niiranen.eu/crm/2013/10/getting-your-head-around-dynamics-crm-2013-processes/
Related
Wondering if anyone can help a total newbie to Dynamics 365. Have started working on an existing implementation of Dynamics 365 (on premise) and am told by current developers that under no circumstances can I amend a column in a table for one of our entities directly on the DB. I am simply wanting to default an INT column to value 1.
They tell me "Dynamics is a black box and you will be breaking the law if you amend directly". This can't be true can it?
Thanks for any advice you can offer.
Building on what Josh said, it is true that the Dynamics SQL database is a black box. Everything must be done through the API with the exception of creating custom indexes on tables and reading from the "Filtered" views.
(And with the new T-SQL endpoint in preview for the online product, you're able to run SQL select queries against an online org.)
The reason for this that all events in Dynamics go through the "platform" via messages. For example, you might have plugin or workflow automation that triggers on the Update of an Account. When the platform receives the "Update" message for an Account, it searches for subscribers to that event and runs any subscribed processes. If you write a change directly to an Account record in SQL, you deprive the platform of the opportunity to run its processes for that event.
And it is good to note that Microsoft uses the same event framework for internal events. So, if you say, "Well, I have no custom plugins or workflows running on the Update message for Accounts so I can edit Accounts directly in SQL." By doing so you'd still risk breaking an internal Microsoft process that triggers on that event.
In a nutshell the platform's need to process ALL events is why direct updates to the database are unsupported. If you do them, Microsoft will refuse to support your system.
Another consideration is that if you ever want to move to the Dynamics Online, writing to the database isn't even possible, so you'd have to redo any automation that relied on that. This is another reason why everyone generally accepts the need to customize their system in the supported way.
Do people occasionally do unsupported things, with good justification? Yes, perhaps most commonly in making unsupported changes to the UI. Even so, writing directly to the database is among the highest offenses to be avoided.
Back to your scenario... it can be jarring to discover that the SQL database is off limits for any direct writing or schema changes. Fortunately Dynamics provides many other automation "hooks" including client-side JavaScript, Business Rules, Power Automate Flows, workflows, and plugins (synchronous and asynchronous).
To set a default value in the UI, the options include a Business Rule and JavaScript. To set a default value in the database, a synchronous workflow or plugin would do the trick.
The Developer Guide is a good place to start.
This would be considered an “unsupported” customization by Microsoft. If it breaks something in the logic of the app, Microsoft won’t help you fix it. If you ever move to Online instead of On-premise, you won’t have this ability. The current developers are battle-hardened and are trying to help you. This is a very bad idea - better would be to create a plug-in on Create of that entity that sets up default values for null fields. This way your logic is in the app with all the other custom logic and is supported.
I have a logic question regarding the capabilities of automatically resolving Microsoft Dynamics 365 CRM (or similar platforms) cases. I utilize an Access database to create emails to send to customers with specific data, while copying my team email to keep track of communications in Microsoft CRM. This action creates a new case in my CRM, which I then need to "Work On" case, add my specific operational catalogs and affected contacts, then finish case as Resolved just to ensure tracking in the CRM system.
My team is currently testing out the capabilities of XML coding in the email which allows the CRM to automatically capture the case specifics described above, however they still need to go in and resolve each case at the end of the day.
After some research, I see that a workflow may be able to do this job of automatically Resolving cases. Is this a possible function for a workflow or plugin to do? Alternatively I have been told by my IT department that we need to have a robot built to complete this task, but I would like to keep this as efficient (and cost savvy) as possible. Any input or suggestions are greatly valued and appreciated.
Thank you!
There are two ways you can solve your problem.
If you want to close all the "CASES" by the day end you can schedule
a "System Workflow" that will execute daily at a specific time and
"Close/Resolve" all the open CASES in your system. Please find below
link on how to setup a "Schedule Workflow" in Dynamics CRM Create
Recursive or Scheduled Workflows in CRM
You can resolve specific cases on Dynamics CRM using C#. Please find below link on how to resolve case using C#.How to close cases in crm 2011 programmatically
Yes. Workflows can be used to close Case records in CRM
If you have the resources (staff) available to write CRM code, you can do it via Code (C#) as well
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
We recently faced an issue with Process entity privilege which could well be a design problem in Dynamics CRM itself. Or may be we're doing something we're not supposed to.
As you all know Process is a common entity for new Custom Action feature and the original Workflows. We used a few custom actions in the system to improve form load performance and make some processes transaction aware.
The problem is that users need organization level read access on Process entity to make a call to these custom actions which is ridiculous. There was a requirement for users to have limited access to workflows but since the custom actions and workflows share the same privilege through Process entity, this is impossible to fulfill.
For server side custom pages and plugins we can impersonate as a privileged user but most of these custom actions are being called from JavaScript (we used it to speed up form load by aggregating queries into single web service call)
Is there a way we can limit users access to workflow and still be able to let them call custom actions?
Another question is that are custom actions not meant to be used in this way? Which, if no, would makes custom actions quite useless.
Thanks in advance!
When deploying plug-ins for MS Dynamics CRM, using the CRM plugin registration tool, you can set secure and unsecure configuration values. You can the setup a constructor to access these values in a plug-in. Is this or something similar available to custom workflow activities? If so, how is it used?
Sadly, there is nothing comparable for workflow activities.
For this purpose, we usually define input parameters for the workflow activies. The configuration is then entered in the workflow designer.