We have recently made our last push to CRM 2016 (on-premise). Our Support team has suddenly noticed that for any given Case under [General > Contract and Product Information] it has started to list ALL Active Environments. In past, it used to only show a linked Environment to the given Case.
Dropdown image:
Similarly, for each given Case under [Invoice Products] its listing all Products.
Here are the troubleshooting steps:
Make sure relationship exists between the entities & its searchable
In Subgrid properties, verify the Data source section for the option - 'Only Related Records' selected in Records
If there is no direct relationship between entities, some JS webresource might be used to filter records using fetchxml - this may be broken
Related
I am trying to import product table data using Azure data factory to Dynamics 365 sales and it is being imported successfully. However all the products are in draft state, even though I had set the statecode (Status) value to 0 as in the documentation, 0 is supposed to be the value for Active.
You can try to update both "statecode" and "statuscode" with valid values as they are related to each other, maybe "statuscode" holds non valid value that prevents you from updating the "statecode.
check the below URL for more info:
https://powerobjects.com/2020/03/11/how-to-programmatically-set-the-status-code-field-of-a-dynamic-entity/
Dynamics CRM OOB Product entity is little different. You have to publish the created products in draft by default.
You can change the system wide setting though.
I want to update the status using single common way in c#.
For now I know about SetStateRequest but it did not change its status to any of status. e.g. If i want to change status to fulfilled for order or canceled for order then it requires FulfillSalesOrderRequest and CancelSalesOrderRequest .Like wise different different class for quote's status and others.
So I want some common way for change status.If is there any solution please suggest me.
If you are on CRM 2015 Update 1 or later, SetStateRequest has been deprecated in favor of a normal UpdateRequest, as seen on MSDN:
Before Microsoft Dynamics CRM Online 2015 Update 1, specialized
messages were required to update certain entity attribute values. Now,
UpdateRequest can now be used to set these attributes. The following
table identifies the specialized deprecated message requests and the
related message attributes that can be updated using UpdateRequest.
With that being said, FulfillSalesOrderRequest (and the corresponding Requests for quotes) have not been deprecated, so you still need to use them going forward. The common reqeust you are looking for does thus not exist.
when saving a modified account form on a MS Dynamics CRM 2015 on-premise installation I recently get an error:
Dependency Calculation
The dependent component EntityRelationship (Id=5288430f-7abf-e511-80cd-000d3a203473) does not exist. Failure trying to associate it with SystemForm (Id=e284b20f-a66d-4019-9a96-83d6ce65847e) as a dependency. Missing dependency lookup type = PrimaryKeyLookup.
This message is not quite useful to me to fix the problem.
If I want to fix it, where should you look for ID "5288430f-7abf-e511-80cd-000d3a203473" and which toold would you use?
You could try the CRM Metadata Browser. This is included in the tools folder in the CRM SDK that you can download for free. It is a managed solution that you have to install into CRM. Once installed you can use it to view information about your entities and their attributes
MSDN Page for Metadata Browser
Select your entity; This will then list all the attributes that belong to the selected entity, in this case Account
You can then look through all the relationships and look for the Metadata ID property of the record. For example, here is the ID for the Primary Contact relationship
You will probably have to examine all these relationships manually to find a match though.
Hope this helps
I'm evaulating Dynamics CRM 2011 currently so I'm still learning how things work.
If a field marked as read-only on a form, is it possible to update it via a process step "update record"? I was trying to have some sort view-only fields that get dynamically updated via a process but in the interface those fields are not accessible to be set?
What if I wrote my own plug-in - would these fields still not be updateable via the assembly?
In order to update a readonly field with a workflow, you have to set it writable until you have the workflow configured. The field will then be accessible and you can add your update action. After that you can set the field to readonly again.
Plugins are not affected by this setting because it is only used for the forms.
I'm having this issue on several server environments.
We have a list at the site collection root. There is a site column created as a multi-value lookup on that list's Title field. This site column is used in document libraries in subsites as a required field. When we upload anything but an Office 2007 document, the user is presented with the document metadata fill-in screen (EditForm.aspx?Mode=Upload), the user fills in the appropriate data (including picking a value(s) for this lookup), and clicks "check in" - the document is checked in as expected, with the lookup field's value filled in.
With an Office 2007 document, this fails. The user selected values for the lookup field do not ever make it to the server - no errors are thrown, but the field is not saved with the document. We have an event listener on these document libraries, and if we inspect the incoming SPListItem on the event listener method before a single line of our code has run, we see that the value for the lookup field is null.
It smells like a SharePoint bug to me - but before I go calling Microsoft, has anyone seen this & worked around it?
Edit: the only entry I see in the SP trace logs relating to the problem:
CMS/Publishing/8ztg/Medium/Got List Item Version, but item was null
Wound up having to open a ticket with Microsoft for this one, and found a bug in the MSDN documentation to boot.
In order to get a multiselect lookup, we had been setting the "Mult" attribute in our lookup field CAML to "true" in the XML we passed to SPFieldCollection.AddFieldAsXml. However, even though the API will throw no errors & appear to work in the UI, this clashes with how Office 2007 & 2010 documents & their SharePoint integration works.
The official, supported way to add a multiselect lookup field is to use the LookupMulti field type in the Field CAML. Doing this, and setting the "Mult" attribute to "true" gives the result I was looking for.
The MSDN documentation for "Mult" has still not been updated for the SP 2007 documentation, and can safely be ignored as it is completely wrong.