making one attribute inherit the value of another in the same entity
-
15. februar 2009 10:33Is it possible to make customise an attribute so every time you change its value, this value will also be passed on to another attribute?
Here is why: I decided to replace the Country text field in addresses for CRM entities with this attribute (these entities being Addresses, Accounts, Contacts) with a N:1 relationship with a new entity called Countries. I started with the Accounts entity.
The thing is, many CRM views and reports for these entities make use of the default/original Country attribute. What I would like to do is that when a user selects a country in the lookup list, this value will be passed on to the original Country attribute as well.
Is this possible?
I tried to set-up a mapping but I couldn't get it to work (the mapping is created successfuly, though). Here is the mapping I did for the N:1 relaitonship between Countries and Accounts:
Source Entity attribute (from the Country entity): new_name (the Country name)
Target Entity attribute (from the Accounts entity): address1_country (the original Country name attribute from the Accounts entity)
However the mapping doesn't seem to have any effect. Any ideas?
Regards,
P.
Alle besvarelser
-
15. februar 2009 11:30This is very possible, you can do it one of two ways (depending on your setup).
If both are displayed on the form just make a quick JavaScript to change the out of the box country. You can hide it with JavaScript if you want.
The slightly more complex, and IMHO a better way, is not to have the out of the box address country filed on the form at all, just update it with a plug-in when you create or edit records on those entities.
-
15. februar 2009 11:45The idea is not to show both fields in the form (well, why would I).
So when you say plug-in, do you mean Visual Studio development, or some script I could add into the form?
-
15. februar 2009 13:35 I'm thinking you could do this with workflow triggered on the change on the lookup field if its v4.0.Essentially when the field changes you update the original Country field value with the lookup value. If you're no longer displaying the field, go to the 'other fields' tab when setting up the update.Leon Tribe
Want to hear me talk about all things CRM? Check out my blog- Foreslået som svar af Leon TribeMVP 15. februar 2009 13:35
-
15. februar 2009 15:45Leon,
Yep workflows could do the job, but I am thinking how processor hungry would this be? There must be a clever way to to this... I was hoping that the form's onSave event would allow me to update an attribute even if it is not visible on the form...
-
15. februar 2009 17:47 Workflows are processor intensive, especially if a lot of them are running. There is a known issue of the async service stopping for no apparent reason, and that stops all workflows too.
If you want to use JavaScript you will have to have both fields on the form. One trick we use for those situations is to move the one you want to hide to a tab like Notes, and then use JavaScript to hide it on the form. It has to be on the form because only then can you call it using the crmFrom.all.new_attribute.DataValue
And yes, when I says plug-in I do mean Visual Studio development, but it is a pretty easy to do. If you haven't done any I feel obliged to recommend David Yack's excellent CRM as a rapid development platform to get you started. Basically what you want is a very simple plug-in that will work on create and update event, and just copy the value from your custom field to the default address1 field.
- Markeret som svar af DavidJennawayMVP, Moderator 22. maj 2009 16:57
-
15. februar 2009 21:39
Unless accounts are changing their countries frequently or we have a large number of accounts being created everyday I don't think this workflow will clog up the server. With the arguments presented one would think there is never a good time to use workflows.
While there is definately a place for jscript (try displaying summary values without it), simple workflows often do the job, are easily maintained by anyone that has the technical ability to build Outlook email rules and do not require expensive developers to build and adjust.
Sure, heavy de-duping or importing can weigh down the processor but I'm yet to see a CRM Server turn to treacle over a field update.Leon Tribe
Want to hear me talk about all things CRM? Check out my blog
http://leontribe.blogspot.com/- Markeret som svar af DavidJennawayMVP, Moderator 22. maj 2009 16:57
