Hi!
I have three fields in a table (Exposures) that all relate to another table (Contacts) in a 1:N relationship.
This is from the metadata:
<NavigationProperty Name="acg_DuplicateSearch" Type="mscrm.contact" Nullable="false" Partner="acg_hmn_exposure_DuplicateSearch_Contact">
<ReferentialConstraint Property="_acg_duplicatesearch_value" ReferencedProperty="contactid" />
</NavigationProperty>
<NavigationProperty Name="hmn_exposedcontactid" Type="mscrm.contact" Nullable="false" Partner="hmn_contact_hmn_exposure_exposedcontactid">
<ReferentialConstraint Property="_hmn_exposedcontactid_value" ReferencedProperty="contactid" />
</NavigationProperty>
<NavigationProperty Name="hmn_sourcecontactid" Type="mscrm.contact" Nullable="false" Partner="hmn_contact_hmn_exposure_sourcecontactid">
<ReferentialConstraint Property="_hmn_sourcecontactid_value" ReferencedProperty="contactid" />
</NavigationProperty>
And I have all three fields on the "Exposure" form (they mean slightly different things to the business, but all relate back to the Contact table).
However, when creating a new Exposure, and clicking Save & Close, the acg_DuplicateSearch field is NOT saved. Only when the business user goes back into that form, and adds the lookup value, does the field retain its data.
I've removed all JavaScript from the form, and I've reviewed the Workflow Processes & Flows -- nothing is making this happen.
The only thing I can think of is: there's a problem with the relationship between Exposure & Contact -- and it has to do with the three fields.
As a point of reference, here's the metadata for Contact, which only lists all the relationships:
<NavigationProperty Name="acg_hmn_exposure_DuplicateSearch_Contact" Type="Collection(mscrm.hmn_exposure)" Partner="acg_DuplicateSearch" />
<NavigationProperty Name="hmn_contact_hmn_exposure_exposedcontactid" Type="Collection(mscrm.hmn_exposure)" Partner="hmn_exposedcontactid" />
<NavigationProperty Name="hmn_contact_hmn_exposure_sourcecontactid" Type="Collection(mscrm.hmn_exposure)" Partner="hmn_sourcecontactid" />
But when looking in the Classic view of the Contact entity, I see the relationship only once:
What could be preventing the field from saving?
Solved! Go to Solution.
It turned out to be a workflow process that was conditionally setting the field to null, which we finally saw in the audit log. I didn't catch it because it wasn't packaged in the solution -- it took going to the "All Processes" view from the "Process Center" to see it.
Hi @JosephCrockett,
What's the exact error message? You can get it by clicking the download log from the error window. Would it be possible to share a screenshot? Also have you checked if you have any plugins registered on the create event of the entity/table? Thanks
Thanks for the help @EricRegnier !
No error message -- it just doesn't save that one field. It does save the rest.
No error messages in the console either. No plugins in our environment.
Screenshots:
Add Mary Jones to Source Case field (with proof of API call to contacts!)
What I guess is the POST saving the exposure entity (Look! It has Mary!)?
But when we re-open the record, there is no Mary. And Mary is not related when I query via the API.
So IF I found the actual POST correctly, and IF I am not missing anything else -- how is it that either the save doesn't happen because of the relationship, or is there something else?
Again, no other JavaScript on the page, and no Flows happening on this entity.
There is a D365 workflow process, but even when I deactivate the workflow process, it still doesn't save.
What else could it be that's clearing this field?
Any Business Rules?
Also, how is the missing value being set - by your code or manual user selection - if your code you probably are not marking the field 'dirty'.
Thanks @Fubar --- no business rules that relate to this, and it is by manual user selection.
There is a business rule, but I don't see how it could relate. For documentation purposes, it sets the visibility and requirement of another field based on a choice:
So... it is sometimes by end-user selection. And sometimes the record is created from a sub-grid of another entity, in which case it DOES save the relationship.
So: there is a third entity, the Assessment table. Exposures are N:1 related to Assessments. Assessments are N:1 related to Contacts.
When an exposure is created from a sub-grid on the Assessment, it DOES relate the contact correctly --> in fact, it even comes pre-filled-out, as the Assessment already has a contact. Does that make sense? How do I better document that?
So when it doesn't work, you have a form that has all data that you want saved visible on that form, and the fields are definitely not marked readonly?
It turned out to be a workflow process that was conditionally setting the field to null, which we finally saw in the audit log. I didn't catch it because it wasn't packaged in the solution -- it took going to the "All Processes" view from the "Process Center" to see it.
Stay up tp date on the latest blogs and activities in the community News & Announcements.
Mark your calendars and join us for the next Power Apps Community Call on January 20th, 8a PST
Dive into the Power Platform stack with hands-on sessions and labs, virtually delivered to you by experts and community leaders.
User | Count |
---|---|
14 | |
5 | |
4 | |
4 | |
3 |
User | Count |
---|---|
20 | |
6 | |
6 | |
5 | |
4 |