I have a custom parent entity named Artist which has a child entity named Album that I need to map to it. It would be an (Artist)1:M(Album) relationship in that instance.
Currently, on the artist form I have created a quick create form for adding albums to a subgrid. When I click save on the quick create form it creates the album. When user updates the "Finished" field on the Artist form and saves, I need to create an **AlbumSummary* record for each album associated with the Artist.
Im new to dynamics so not sure how to do this or if its even possible to do Out of the box.
This is definitely possible in Dynamics.
I suppose you would like to go 'no code' approach. Taking you data model in mind, this can't be easily done using workflows (https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/customize/workflow-processes). Cause they don't do well on working with relationships. There are no queries and cycles through result records in workflows.
Your example may be a bit abstract, but still let's consider some business logic changes that make it possible to use workflows.
If it is one-to-one relationship between Album Summary and Album, then you can just incorporate that summary data in Album itself. And not use Album Summary entity at all.
Album Summary may be easily created on Album creation event. Also doesn't fit well exactly your requirements.
If these are not an options for you, then you will have to go with code approach. You will need to develop plugin or WF activity in C#.
If you are using D365 online with good license plan you can investigate Power Automate (no code) usage.
At the simplest form within Dynamics CRM, it's all about understanding what your triggering events are, and what actions you'd like to take. In your case, you've stated your triggering event is the user updating the "Finished" field on the Artist form. This feels like a bit of a code smell here. Just not sure what "Finished" means for an Artist. Most likely, you want this logic to take place either each time the user adds an album, in which case it would be the creation of the album that should be your trigger. If you'd like your logic to kick in for every album, only when the user chooses, then you might think about creating a ribbon button for this purpose.
Once you've determined your trigger you have quite a few options for performing your actions. Simplest for developers are creating plugin, that you deploy and register to run on the particular event (create/update) of the particular entity/attribute. Simplest for non developers would be a MS Flow (if online) or a Workflow.
So to answer your question, yes, it's supported, just with some supported custom logic.
Related
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'm creating a web app for my client as a part of my schools final project.
It's a web app where users fill forms (surveys) and after forms are submitted,
values are saved in the database.
There are three types of users: admins, moderators and viewers. Admin's can see the
overview of filled forms, moderators will fill these forms and they also can make edits
to them and get the overview of the forms they've filled. We haven't discussed about the rights of viewers
at this point.
I'm using CodeIgniter as a framework of my project since it comes pretty handy when it comes to database
manipulation and forms. What would be the best way to implement this kind of situation? There are apprx.
4-5 forms (surveys) each moderator will fill. After they've filled them, they only can make edits to that particular form.
So one user can fill each form only once.
I've designed that each of the forms needs one table. So if there is a form (survey) about IT equipment, I will create
a table for IT equipment. User's id number will be saved in to the last column in the table, usually called "user_ID" where I can
make queries based on users and check if user is already filled the particular form.
What about controllers and models? I've thought I could only make one model for inserting and editing the form.
However, is it pretty much the only way to create a controller or method foreach form since there are different types
of form fields to validate based on the form user is actually filling. I've already created a controller for inserting and updating
the IT equipment form and both of these methods are pretty big when it comes to the amount of code, over 200 lines per method.
So that would be a total amount of 2000 lines of code just for inserting and editing all the forms.
What'd you do and how you'd implement this if dealing with similiar kind of project?
Thanks in advance for all the ideas and point of views!
You should take a look into this:
http://cibonfire.com/
It's a really good addon for codeigniter, that allows you to data oriented development.
I want to modify the view of 'Activity' entity, opened the view and try searching for edit filter criteria option and it's not available on view form.
please see below
Can you please help to advice me on how I can add filter criteria for this view above. Or how to make it visible the option 'Edit filter criteria' on the form of a view.
Any suggestion will be much appreciated. Welcome for any feedback...
I don't know any way to do that, but you can do your custom views and for example change the default view for that entity. With custom view you can change everything.
See here step by step: http://www.powerobjects.com/blog/2008/08/11/creating-and-editing-views/
What you want is impossible to achieve. Pedro's suggestion is your only option. Create your own Activity view, and then you can create your own filters. You definitely cannot create your own Associated Views. Public Views are the only ones you will have a hope of creating or modifying, and in this particular case, you are still restricted.
There are various places spread throughout CRM where you will run into problems like this, where an entity, view, or field is "locked down". This is the cost of starting with platforms like CRM which are a blackbox that only offer customization up to a certain point.
The problem in this specific case has to do with the nature of activities and the various activity types. Under the hood, there really is not a traditional record type for Activities. The Activity entity is really a "pointer entity" (note the internal name "activitypointer"). Activities really point to other entity types (in this case Activity Types) such as Email activities. The Email entity is more of a traditional entity which you can run standard queries against--but even still that is "locked down".
This additional layer of complexity makes dealing with Activities programmatically more difficult (ex. querying the data, modifying the data via a plugin/SQL, etc.) and, in this particular case, makes even the most basic customizations impossible.
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.
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.