We have a business requirement (more financial compliance requirement) to monitor our production instance for any updates/releases/changes. This is to meet audit obligations so that we can prove that all changes were performed only inside of established release processes ie. no one is making changes to the CRM instance outside of this.
To be clear we already have an established release management process, but the question is being asked if there was a way to monitor the CRM instance to prove that indeed no changes are being made outside of release management. We have a Dynamics 365 online instance. I've searched for something suitable but am not able to find anything so the question here is posed to get pointers / ideas on potential solutions to this problem or even pointers to where I could begin my research into potential solutions.
As a background, the CRM application has financial data and hence we have 'over the top' financial controls/legal obligations to meet and hence the requirement.
You can explore this Change Tracking Solution from MS Labs, basically to track all the Publish/Publish All from CRM org.
The Change Tracking solution helps in tracking down the details of changes on who updated an entity, JavaScript, assemblies and processes along with the time of update. This solution is built on Dynamics 365 and as well works on Dynamics CRM 2016 (Online/ On premises)
I never tried this, but this was from a team which I worked earlier in MS internally.
If this not fits you, you can implement a custom plugin on Publish and PublishAll messages yourself. Read more
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've inherited a Dynamics CRM system at work, running: Version 1612 (8.2.2.112) (DB 8.2.2.112) on-premises.
We're in a situation where duplication seems to be happening intermittently via failed form submissions, with a subsequent re-submission. We've internally released a document explaining this behaviour and expressed how important it is to check first if some or all of the transaction actually succeeded. But humans will be humans, and often forget...
With that said, as a DBA, my first instinct was to create a unique constraint/index. However, it's not clear to me how to best accomplish this in the scope of Dynamics. I'm not confident in the application-level Duplication Detection that's available built-in, and Alternate Keys don't work for us since many of our unique constraints require the inclusion of a DATE field or two.
From what I can tell, adding indexes to the CRM base tables is a supported DML action, but indicates that it prevents upgrades. Does this mean that we can't upgrade in the future? Or simply that the indexes will not be migrated during the upgrade?
Are there better solutions that I'm missing, which offer database-level consistency and don't impede upgrades?
With on-premise CRM you can add indexes, and it does not specify that this does not extend to clustered indexes. I very strongly recommend indexing CRM databases for performance. Per the developers guide:
For Microsoft Dynamics 365 on-premises deployments, adding indexes is
supported per the guidelines in the Deploying and administering
Microsoft Dynamics CRM documentation. This applies to all Microsoft
Dynamics 365 databases and the Microsoft Dynamics 365 for Outlook
local database.
(I don't actually see anything related to indexes in the documentation mentioned above)
I am not sure which documentation you are referencing regarding upgrades not supporting these indexes, I have never experienced any difficulty upgrading CRM orgs with databases I indexed. However, there are apparently issues with upgrading to v9 related to full text indexes:
https://community.dynamics.com/crm/f/117/t/242951
Also if you ever move to CRM online, this entire approach will no longer work.
The approach which IS supported with all CRM environments is to write a synchronous pre-operation plugin which checks your uniqueness condition, and throws an InvalidPluginExecutionException. This exception can include a user friendly message which the user will receive in the standard error pop up window when they try to create a duplicate. This is guaranteed to be nicer experience than whatever happens when the application violates an index constraint.
I enforce contact email address uniqueness using this method and it works very nicely. I have a duplicate detection rule set up, and if the user ignores the duplicate warning and creates the contact anyway, they receive a message that duplicate email addresses are not allowed.
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
I have built a platform that in essence allows users:
to create a company profile and invite your colleagues,
create an office with a floor plan,
add tables and meeting rooms to the floor plan with each meeting room having a separate calendar,
book tables and meetings in meeting rooms.
The platform is built on Python/Django.
Now I am trying to implement a sync mechanism that would work with Office 365 and local Exchange distributions. The sync would be two way, that means an event created in Outlook would trigger an event to be created in our system and vice versa.
My first attempt was to use the EWS SOAP API (with exchangelib). But soon I've run into problems when figuring out how to create triggers for Outlook events. This ended in failure as synchronization would involve constant bombing of slow API-calls such as iterating through accounts and checking if anything changed in their calendars.
Second attempt involved using the Microsoft Graph API that has this neat push notification feature that would solve polling (or so I thought). But as I later found out, having the administrator link his privileged Exchange account and then being able to subscribe event changes for all associated accounts in one go was not possible (thanks to this article). So again this lead to the realization that polling (or making everyone link their personal accounts) was the only way to go.
What approach would you recommend to achieve two-way sync with Exchange that would involve only having the admin do the account linking with as little overhead and polling as possible?
Is there anyone who have developed large-scale applications that do something similar? If so, can you push me in the right direction?
A bit late to the game here, but maybe what you want is the EWS SubscribeToPushNotifications service. It's not implemented in exchangelib yet, but there's a ticket for it https://github.com/ecederstrand/exchangelib/issues/145
Implementing the basics should not be difficult.
My client is doing an upgrade from CRM Dynamics 4 to 2011 and it uses BizTalk 2009 as its ESB, they are currently using the 'Microsoft BizTalk Server Adapter for Microsoft Dynamics CRM 4.0' for the Integration, my question is does anyone know what breaking changes are involved from a BizTalk point of view when this upgrade takes places?
Am I looking at a whole new set of contracts in CRM 11 e.g. WCF meaning code changes, mappings, schemas and moving away from the Adapter (4.) to pure WCF transport communication?
At this moment in time I'm trying to gauge the complexity and migration levels for one service...
Cheers
I have some first hand experience integrating BizTalk with CRM Online 2011.
The major difference is the change from the pre-defined CRM types, allowing compile-time type safety, to an un-typed Wcf interface. A couple of (ugly) solutions to this problem have been documented around the web, but this blog post by Richard Seroter defines a BizTalk-only solution.
We used a third-party supplied adapter, developed by Roedl in Germany. This uses the Wcf Adapter Framework, in a similar manner to the WCF-SQL adapter, to provide a set of compile-time strong-typed schemas. This made it simple to map to and from the CRM types to our legacy system data types.
One disclaimer, we found that performance was "sufficient", without being outstanding. If you need to move a LOT of data back and forth, consider using the bespoke solution, but if lower development cost is your prime motivation, it is worth considering.
The scope of this project as described will be huge especially considering the limitations of the BizTalk Server Adapter. Have they considered using Scribe? You might want to do a simple proof of concept project for them with the free evaluation version. Scribe downloads