Is there a way to start business rule execution using crm sdk? It has configured Entity scope.
Thanx.
If the business rule is set for server side execution I think you should just have to do something that triggers the business rule. Rather than calling the business rule explicitly.
E.g. if business considers some field in a condition, then change that field.
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.
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!
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/
For my current project I have to add a record to a database when a custom workitem changes to specific states. For this you can build a TFS plugin which fires at the WorkItemChanged Event. However our company policies don't allow us to build these plugins because it is processed for each workitem in all projectcollections. This action is only needed for a few team projects.
My question: is it possible to create some clientside plugin(perhaps a VS plugin) which fires an action on this event instead? Or is there someway to create another sort of listener to this event?
Any suggestions would be greatly appreciated, thanks in advance.
Instead of having TFS drive the alerts for you, you can implement a polling based alert system.
I would create a simple work item query that selected the work items you were interested in and sorted by the Changed Date column. Then I would write a simple program that used the TFS SDK to run this work item query and notify based on the results, keeping a high water mark between polls. (The TFS SDK samples has an example of running a work item query.)
Note that this polling-based approach has advantages over setting up a SOAP listener regardless of your corporate policy. The SOAP-based alerts system that TFS uses was developed for communication between components of the TFS infrastructure. It's expected that the SOAP endpoint you configure is high availability - if your machine goes down, the SOAP service crashes or your IP address changes, you'll start seeing TFS complaining in the event log. I filled up the event log on my TFS server before I switched to a polling based model for a similar alert system.
In the end I created a custom control for in the WorkItem editform. Within this control I could implement all the required logic for creating the database record.
So instead of setting the combobox state to the onhold state, there now is a button which does exactly the same, executes my custom coding and thus adds a record to our database.
I'm evaluating CRM 2011 to replace an existing app and and have some questions about security and segregating information by Client (or Account).
I have a custom entity for 'Client'. There are lot of custom entities that are related to 'Client' which consitute the data needed to be captured.
I would like to limit specific teams/users to work on specific clients and see only the data for those clients that they have access to.
I'm seeing that individual entities can be assigned to teams/users but I need all related entities to be locked down by Client so that regular users
Dont see records in views or searches that belong to other clients.
Can't create or access records for other clients.
Can this be done in CRM 2011? How?
Also - is it possible to limit processes/workflows to operate or trigger on records of specific clients only?
Probably the easiest thing to do would be do base your security on business units. Groups of clients an their related records would all be in the same business unit, and as long as you set their security roles to only allow access to records in their own business unit, that would work.
For workflows that only trigger on particular clients, it depends on the exact requirements. You could certainly check the business unit of the client as the first step in the workflow and continue or exit based on that. If it's something more complex, you can write a custom workflow assembly to do the check for you.