Title basically sums it up.
I have an Account screen, with a sub-grid of Opportunities (by the "parentaccountid" field of Opportunity). When I click + Add New on that Opportunity grid, it autofills parentaccountid on the new record form. That's normal.
BUT I also have 5 other Lookups to Account on Opportunity, with different/specific meanings. What's weird is that it's setting ALL of those Lookups to the Account record I started at (Account record that had the Opportunity subgrid where I clicked +).
Is this expected behavior?
Anyway to change this?
I'd expect CRM to only autofill the field that defines the association for that subgrid (i.e. only auto-fill parentaccountid in this case, leave the other 5 Account lookups blank)
I never experienced this, but I believe this is due to some OOB relationship mapping according to a community thread. Read more
Try to find the mapping under N:1 relationships, and if possible remove the mappings. Otherwise you may need to use the Business rule, script or plugin to remove the auto-mapped values.
Edit:
This explanation makes sense and it is expected behavior as per product deisgn.
Since there is an out of the box parental relationship (opportunity_customer_accounts), all those additional account lookups are automatically mapped to that same "parent" (accountid field), and, since they have already been mapped automatically, you can't map them to another field
Related
Background
Each Dataverse table contains a primary name column. When displayed in a subgrid, clicking on the primary name column will navigate to the form so that the user can edit that row. Most subgrids in my application work this way.
The Problem
I have a Course form with a list of participants displayed in a subgrid. The subgrid displays each student's name (as a link) and the grade received in the course. There is no appropriate primary name column for this Participant table. To edit the participant record, the user must select the row in the subgrid, then click the subgrid's Edit button. As a result, this UI is different from all other subgrids in the application and I know that user's will click the student name to try to edit the participant record and be confused when they are presented with the student record.
Am I missing something? Is there a better way to handle this?
It's a common problem I face quite often. Here is usually what I would do.
Make sure the Primary Name Column always contains relevant information to the user to be able to quickly identify a record. Sometimes it requires copying information from one or multiple other columns into the primary column.
In your case that would probably means concatenating the student's name and grade.
How to do that?
Common to all solutions below
Use one of the following solution to copy the content of one or several fields into the primary column.
Make sure the solution you select also updates the content of the primary name column when one of the copied field is updated.
Remove or hide the primary column from the form, the name of the record will be displayed at the top of the form anyway and you probably don't want users to play with it.
Display the primary name column in every subgrid.
I would recommend not adding the fields copied into the primary column in the subgrids to avoid confusion.
Solution 1 - Classic Workflow
Create a classic workflow that runs when a record is created / updated
Pros:
Very quick to put in place
Runs synchronously (users will see the name updated in real-time)
Cons:
Not very practical if you need to add business logic (using different fields as source depending on a certain condition for example)
Solution 2 - Power Automate
Create a Flow that runs when a record is created / updated
Pros:
You can implement complex business logic in your Flow
Cons:
Runs asynchronously (users will have to refresh the page after the creation of a record to see the record's name)
According to Power Automate licensing that flow would certainly be considered as an "enterprise flow" and you are supposed to pay 100$ / month. That specific point must be taken with a grain of salt. I had several discussions with Microsoft about it and they haven't given me a clear answer about what would be considered an enterprise flow.
Solution 3 - Plugin
Create a plugin that executes when a record is created / updated
Pros:
You can implement very complex business logic in your Flow
It can run synchronously
Cons:
Pro-code (I put it as a con since Model-Driven App is a low-code / no-code approach but there is nothing wrong about pro-code per say)
Developing a new plugin for each entity where you need this logic is kind of overkill in my opinion. I would consider developing something very generic that would only require some sort of configuration when the logic needs to be applied to a new table.
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 added a new entity to my Solution in Dynamics Online 2016 Update 1 which is used to log the details of a physical computer (named System). This entity needs to have an address associated which may not be the same as the linked Account and Contact records.
How do I include an address field(s) in the same way that the Account and Contact entities do, that has a multiple line input field which pops out to multiple single line fields when clicked and links to a Bing maps location beneath it?
If this is not possible (and I really hope it is) then what is best practice for associating street addresses with custom entities?
what you describe is known as the composite field and it's not possible to create custom fields with the same flyout style.
Regarding the address, you can proceed as you prefer, create the fields or create a separate entity, or what you think suit your requirements.
I have a custom entity Stuff and it contains a lookup to Contact. I created a 1:N relation with the latter as primary and the former as related entity.
On the Contact's form I added a subgrid and I only wish to list the instances of Stuff that have the lookup pointing to the currently viewed Contact. However, when I choose Only Related Records, the custom entity isn't in the list (despite it being related via the 1:N relation).
So, I'm using All Record Types, instead, but that shows all the instances of Stuff and not, as I wish, only those that are related to the currently viewed member.
So, what's the best course of action here? Should I do something with the relation? Or build a custom filter in JavaScript? How can I make the Stuff related to Contact if it's at all possible?
The image below shows the available conditions for the related entities. I notice that none of them relates to Contact, though. Do I need to activate it somehow or am I approaching it from a totally wrong angle?
So to give you more detail, you add the grid on the form:
(This is coming from the contact Form edit, after you press add subgrid)
you select there only related records, this are the stuff record i created:
As you can see only 3 of them has a lookup pointing to a valid contact, from there if you look at the grid, is showing only the related ones as you selected during the grid creation:
In any case i update the answer this is how the relationship is defined, and is a simple lookup created from the stuff entity:
Is it possible to set null/blank lookup values on relationships in CRM 2011 when they open from the parental/referrential entity?
Example, if you create a new 1:N relationship between the entities opportunity and account holding an agency value. When creating a new opportunity from an account, this account is prefilled in both the potential customer lookup field and the agency lookup field.
This can easily be remedied with a javscript, clearing the field onload, but can this be done earlier, in the attribute mapping, or is it always a post-fix to correct the default action?
I had the same issue in Crm 4. So I suppose it still exists in 2011.
You cannot remove the relationship mapping of the primary attribute, though I've never understood why this automatically maps to fields of different relationships.
In this case you are just best off using JavaScript to perform the following logic:
If the form is in create mode and both fields contain the same value then clear the duplicated field.
This logic should ensure that it only clears the fields in this circumstance.
This is not possible without Javascript.
MS CRM doesn't give you an option to counter the autofill of the mapped field. It will always be automatically filled in by the system.