I'm new to dynamics CRM, and I'm wondering if, and how, the following scenario can be supported:
When a record is created / updated, I want to be able to define how to find duplicate records.
If a duplicate is found, I want to be able to define automatic actions based on the new record's properties.
(for example- when a case is created, check for duplicate cases based on 'customer' and 'owner' fields. If a duplicate is found, then: if the duplicate case's status is not 'active' then go ahead and create a new record. otherwise- update some of the existing record's fields based on the new record).
The first part can easily be accomplished using duplication detection settings, but I don't think they allow for any complex logic when a duplicate is discovered.
The second part can easily be accomplished using workflows. however, I don't think that they offer conditions that check other records. I've looked into customizing workflows, but all I could find was how to customize actions, and not conditions.
Does dynamics CRM offer any solution to this type of scenario?
Yes, it does. You can accomplish this using CRM plugin. It should be Pre execution plug ins registered on Create and on Update events.
Related
I am new to CRM. I was reading here that there is a "convert lead to account, contact and opportunity". I understand how it would split the data from lead to account and contact, but I can't see ( from reading the Entity Metadata excel file ) where any opportunity information would be linked to lead.
If I understand your question correctly, you are looking for Originating Lead lookup in Opportunity entity record where the Qualified Lead entity record reference will be stored.
If you want to store more Lead record values into Opportunity record, you can use entity relationship mapping like explained in this blog.
Update:
If you don’t want to create a Contact when qualifying, you will need to associate the Lead to an existing Contact in Dynamics CRM 2015. An Opportunity will always be created regardless of which fields are populated on the Lead.
In fact, if you didn’t fill out a single field on the Lead form (none were set to ‘required’), and Qualified that Lead, you would create a new Opportunity with no information associated to a new Contact that also has no information.
Of course, you can use workflows to adjust these situations as required – e.g. if you never want an Opportunity to be created from a Qualified Lead you could write a workflow to delete the Opportunity on creation (checking to make sure the Originating Lead has a value).
Read more
I am in the process of modifying forms to account for V9 of Dynamics which is being rolled out currently.
Our environment is using Dialogs but these are being deprecated with V9 which means we have to prepare the forms to be used instead of these Dialogs.
Due to how fragmented our solution is the data is all over the place in different entities and can all be written too at different times.
Is it possible to have multiple entities/records on the same form which are all editable? This way I can run rules to hide and show as people edit specific fields.
From what I can identify, there is no "true" way to achieve this. However, if there are entities which are linked via a relationship within the solution, it is possible to add the "Party List" type field to the form and this will act as the link between the two entities. When you go to search for an existing record within the related entity, there is a new button which allows you too create a new record of that entity which directly associated with the form you were working on initially.
We do have editable subgrids. Add the subgrids of related entities & allow users to edit the related records in main record form at one shot.
I am currently leading the implementation of Office 365 for a crowdfunding portal for a UN agency. The portal features stories of survivors of human trafficking. Their cases are generated in Dynamics (for various reasons) and published to the user-facing platform. Each case comprises of a collection of records including various text fields which contain individual story points.
The problem: Those survivor stories are usually generated by teams on the ground but can be diplomatically sensitive.
As such each case needs to go through an elaborate review process to ensure that higher ups can propose changes to the case, make comments for specific fields. Each field can have several (1:n) comments/ change suggestions from n staff (not just one).
It was proposed to collate feedback in a field called 'comments' but this separates the input from the fields the comment was made about. We are now looking for a solution that emulates Word's 'tracking changes' feature.
Options considered but ruled out:
We are aware that Dynamics comes with an audit history module, but this usually requires changes/ comments to be displayed in a separate window which defeats the purpose.
Is anyone aware of a useful workaround which accomplishes one or several of the below:
Flags changes in a particular record per record and next to said record
Allows for said changes to be accepted or rejected by the Case owner
Supports workflow integration and user hierarchies.
Works in Dynamics (not Sharepoint... ... ...)
Any advice would be highly appreciated.
While I am all for creative uses of CRM, and CRM can store the data you're looking for, using CRM as a collaborative document editing system might be pushing the envelope.
Before you build out a custom document editing system, you might want to consider reviewing SharePoint, and some of the other document management add-ons that exist for CRM. While I have not implemented it myself, I have heard good things about LaserFiche.
You might also want to look into a 3rd party editor that provides "track changes" capabilities that you can embed in a web resource on the Case form.
I took a quick look and found this LoopIndex LITE plugin for CKEditor.
If you do go the custom route, here's a potential design for capturing the comments on a field-by-field basis:
Each field could have a separate text box where a user can enter a new comment about that field. A workflow could take that comment, turn it into a new "comment" record which would include the user, timestamp, and text. The workflow would also clear the box for the next comment.
You might also want to have this text box hidden by default for each field and have a checkbox called "Add Comment" (again for each field), which would show the new comment text box.
And you could consider having the new comment text box automatically populate with the original text, so the user can edit it rather than from start from scratch. This could be optional via an "Edit original text" checkbox or button.
To get really fancy you could run a text diff module to compare the updated text and the original, and store the new text as HTML, highlighting the differences.
The approval process would work off the "comment" entity. People could review each comment and approve or deny, with additional "meta-comments".
You could then have a web resource that would compile all existing comments for the field into html and display them under the field, formatted based on their status (i.e. pending review in black, denied in red, approved in green).
While I think this approach can be effective, adding a new field to the survivor's story would have some overhead. Another approach would be to create a Story Field entity and a Story Field Type entity. Let's say there are 5 fields now in the survivor's story. When you populate a story into CRM you'd create 5 Story Field records, each with its appropriate type. And, the Story Field entity would have a 1:N to Comments. This way, adding a new field to the survivor's story template is as simple as adding a new Story Field Type.
My proposal:
Use CRM incident entity or any custom entity as now hierarchy data can be maintained.
Parent incident is field collected record & child incidents can be used for tracking each feedback / comments / change requests from officials.
Build a custom approval mechanism using actions/workflow/plugins based on your team skill set. This can be invoked based on BPF stages in child Case.
On approval (child case closures) the values / comments can be rolled up / incorporated to the parent incident record.
Note: Multiple parallel feedback for overwriting changes can be a challenge, but approval business process flow should take care of this scenario.
I have an custom entity which needs to have a case number for an XRM Application, can I generate a case number from the Service -> Case.
If this is not possible, how can I do this with a plugin, I've looked at the crmnumbering.codeplex.com but this doesn't support 2011, anybody outthere have a solution or should I rewrite it myself?
thanks
I've ran into this same type of issue (I need a custom # for an entity). Here's how you can do it:
Create an Entity called "Counter"
Add a field called "new_customnumber", make it a string or a number depending on what you want
Create a new record for that entity with whatever you want in the new_customnumber field (let's say "10000")
Create a plugin (EntityNumberGenerator) that goes out and grabs that record (you'll probably want to set the security on this record/entity really tight so no one can mess with the numbers)
On Create of the "custom entity" fire the plugin. Grab the value in new_customnumber save it to the "custom entity" (let's say in a "case" field) increment the new_customnumber and save it to the Counter entity.
Warning, I'm not sure how this is with concurrency. Meaning I'm not sure if 2 custom entities being created at the same time can grab the same number (I haven't ran into an issue yet). I haven't figured out a way to "lock" a field I've retrieved in a plugin (I'm not sure it's possible).
You will be unable to create a custom number for custom entities from the normal area you set a case number.
Look at the CRM2011sdk\sdk\samplecode\cs\plug-ins\accountnumberplugin.cs plugin. It's really similar to what you want.
Ry
I haven't seen one for 2011 yet. Probably easiest to write it yourself.
I've always created a database with a table with a single column which is an IDENTITY column. Write an SP to insert, save the IDENTITY value to a variable, and DELETE the row all within a transaction. Return the variable. Makes for a quick and easy plug-in and this takes care of any concurrency issues.
The performance is fast and the impact to your SQL server is minimal.
I've made a custom entity that will work as an data modification audit (any entity modified will trigger creating an instance of this entity). So far I have the plugin working fine (tracking old and new versions of properties changed).
I'd like to also keep track of what entity this is related to. At first I added a N:1 from DataHistory to Task (eg.) and I can indeed link back to the original task (via a "new_tasksid" attribute I added to DataHistory).
The problem is every entity I want to log will need a separate attribute id (and an additional entry in the form!)
Looking at how phone, task, etc utilize a "regardingobjectid", this is what I should do. Unfortunately, when I try to add a "dataobjectid" and map it to eg Task and PhoneCall, it complains (on the second save), that the reference needs to be unique. How does the CRM get around this and can I emulate it?
You could create your generic "dataobjectid" field, but make it a text field and store the guid of the object there. You would lose the native grids for looking at the audit records, and you wouldn't be able to join these entities through advanced find, fetch or query expressions, but if that's not important, then you can whip up an ASPX page that displays the audit logs for that record in whatever format you choose and avoid making new relationships for every entity you want to audit.
CRM has a special lookup type that can lookup to many entity types. That functionality isn't available to us customizers, unfortunately. Your best bet is to add each relationship that could be regarding and hide the lookups that aren't in use for this particular entity.