In Microsoft Dynamics CRM 4.0, I want to be able to check if a record of any entity type is disabled. I think I can check the statecode. From the information I have seen, a value of zero means that the entity is enabled (editable in CRM) and any other value means disabled (for editing in CRM).
Is this assumption correct for all entities?
EDIT
If my assumption is correct, is it possible to create a QueryExpression for dynamic entities that does such a comparison, rather than using the text, "Active", which would be incorrect for quotes?
From what I've read, StateCode is not necessarily the same for every entity. It varies per entity.
I'm not aware of a way to disable an entity. I double checked our install, but don't see any option to disable. Google also yields no results to this end.
Do you mean perhaps individual entity records? If so, you'll have to check the StateCode for the entity you're looking at. I think most entities use StateCode as you describe, but for some entities, such as Activities, it seems to vary a little.
Here is some SQL I found to pull back the StateCode/StatusCode details of a particular entity:
select
AttributeName,
AttributeValue,
Value
from dbo.StringMap
where
(dbo.StringMap.AttributeName = 'statuscode'
or
dbo.StringMap.AttributeName = 'statecode')
and
dbo.StringMap.ObjectTypeCode = 1
ObjectTypeCode 1 maps to the Account entity.
Hope this helps.
EDIT: Just saw your addition. I think you'll be safe using StateCode in most instances. I personally use it in one of my projects to exclude disabled records on the Lead and Contact entities. Just double check the value mapping as I've described and then implement.
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 have an entity - EntityZ, which has a ParentId where ParentId could be EntityA.Id, EntityB.Id or EntityC.Id. Is it possible to create this in MS Dynamics CRM 2016? If yes, how? I've looked but couldn't find a similar question or any help on the web.
An entity can be the child party in only one full parental relationship. When you are looking for a way to cascade record ownership, deletion a.o. between mutiple parent - child entities you can create configurable cascading relationships.
As Arun Vinoth pointed out you can design your entity as an activity type. However, this may conflict with the semantics of activity records in CRM. Also, doing this would make it possible to associate the child entity to any entity that is enabled for activities.
There’s a trade off to achieve this. Custom entity as Custom Activity
Creating custom entity EntityZ as custom activity and EntityA, B, C can act as parent.
EntityA or B or C can be chosen as RegardingObjectId of EntityZ.
This has security limitation like EntityZ will be visible to everyone as this will be listed like other activities (Email, Phonecall, Task, etc)
I think it is worth nothing that Dynamics 365 does contain and out-of-box "polymorphic" customer field.
This field can link to either an Account or Contact:
And while it can be kludgy, another option would be to create 3 lookups and only populate one. Once one is populated you could hide the other two. Or, you could have a "Parent Type" option set to determine which lookup to show.
It would be a bit messy to show three lookups in a view, with only one populated, so you might also want a Parent Name text field in to which you could concatenate the type and name. You could use a workflow to populate it, and then use it in views and reports.
We are using Dynamics CRM 2016 on-premise. When you create a custom entity, you get a default "name" field which is a string with 100 characters. You can change that datatype during entity creation but we didn't do that.
Now we learned that 100 chars are not enough in our usecase, we would need 120 or 150.
The solution designer allows changing the string length but when we save the changes we get a generic database error.
Question: Is there a known workaround to change the string length of the main field?
Obviously, it is possible to create a new entity and copy the data from the old to the new entity. Since we have many views, forms and references between entities, this is not really feasible.
This is not possible using any conventional solutions (i.e. through the UI) due to constraints in the Database. The default name field is the primary key of the table. I encourage you to remake the entity and migrate existing data to the new entity.
If this is really not feasible then you can try to change the length of the column directly in the SQL DB, but that is unsupported so it might break the environment. If you want to try this be sure that you test this in an disposable environment.
I have never done it so I don't know the outcome but that is something that I would try.
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.
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.