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!
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.
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/
My web app has to do some calculations in the background. I've investigated multiple solutions and I would like to go for business logic instead of a SQL job that triggers all the calculations. After a few days of research I'm still not convinced what is the best solution for my case.
A lot of articles mention Quartz.NET, a separate windows service (but I think that's not an option on most shared web host services), a windows task, etc...
To keep the calculations in the business logic I would extend my web application with a dedicated 'task' controller that fires the calculations automatically and then returns a result of its actions.
Q1: Calling the controller with a Quartz.NET timed web request will not be that hard, but how can I secure it? If I add the [Authorize] attribute to my 'task' controller it will block the request. (note that I use forms authentication on my internet web application) I don't want users on the internet to be able to launch my 'task' controller.
Q2: Also if what I'm thinking is correct that shared web host services don't support the installation of separate windows services or remote desktop connections, I'll have 2 options:
hope there is support for windows tasks at the shared web host service (but can this be called with authorization credentials?)
start the Quartz.NET from my application_start (which is certainly not an ideal solution...)
Thanks in advance
Kr
First of, I wouldn't call ASP.NET MVC controller from scheduled job. I'd just delegate to business components / services (whatever the name is) and make sure there that we run correct things with context's permissions. This could mean that I fire the job with information about for whom the calculation is done and pass that information to service component (calculate daily average for user X). I don't see a real benefit from masquerading the call with ASP.NET MVC stack.
So Q1: Secure in code level, not using ASP.NET MVC stack
You can always run without windows service, then you just take the risk of app pool shutting down when not in use. One way to get by this is to have a external ping program that makes sure that there are calls made, not ideal as you pointed out. Having jobs and triggers in database protects from losing information but not from misfires.
Q2: most likely running Quartz.NET is far easier than trying to access Windows Scheduled Tasks.
Some shared providers have very strict settings for code to run. It might be that Quartz.NET won't run at all if too tightly sandboxed.
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.
Is there a way to track user activity in Microsft Dynamics CRM? The end result would be a list of users, showing a datetime for each access into CRM, and possibly what modules are being accessed.
Also, is there a way to tie users to database connections, as is done in AX?
Why do you want to do this? The reason I ask is because there are many different ways to log user access depening on purpose.
Detailed access logging can be performed by IIS (web log).
Logons are also tracked in the Event Log->Security log.
Changes to entities can be tracked by implementing an audit log using workflows (or buying a third party component to do this).
The third option is to write a .NET plugin that logs whatever you want on whatever event you want on the entities you choose. Lookup plugins in the Microsoft CRM SDK for more information on how to do this.