Could we have improved address functionality. The current implementation is
so clumsy. The account address is mapped to new contacts on a one off basis,
so any amendments to the account address will make potentially hundreds of
contacts out of date, and amendments to a contacts address will be missed by
the account.
Also storing 2 addresses for every account and contact means you end up with
a huge number of empty address records.
Can we have a normal relationship with the address entity please?
--
Marge in the uk

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/Businesssolutions/Community/NewsGroups/dgbrowser/en-us/default.mspx?mid=f0acafc4-5fef-49fe-940d-c935125bce7a&dg=microsoft.public.crm

Re: Improve Address Functionality by ChrisC

ChrisC
Tue Jan 22 03:47:22 CST 2008

From your post I guess that in your business all contacts for an
account have the same address as the parent account? Yes, the way
MSCRM works creates lots of empty address spaces but ultimately it is
more flexible.

To tackle your problem, had you considered making a MANUAL workflow
rule for CONTACT that sets each address1_xxx field to the parent
account's address field? Then, after updating the parent account's
address you could call this on all their child contacts. This would
potentially save you a lot of time, plus allow you to exclude from
updating those inevitable exceptions for homeworkers etc.

-Chris
mscrm4u.blogspot.com

Re: Improve Address Functionality by Marge

Marge
Fri Jan 25 09:38:02 CST 2008

No - we have contacts with additional addresses, not necessarily the same as
the account address, and sometimes 30 or more addresses for the account.
Thanks for the suggestion, but it relies on a manual process - prone to
error. I still think there is a more elegant solution if we can create
additional relationships with the address entity, or even bulk edit the
address
--
Marge in the uk


"ChrisC" wrote:

> From your post I guess that in your business all contacts for an
> account have the same address as the parent account? Yes, the way
> MSCRM works creates lots of empty address spaces but ultimately it is
> more flexible.
>
> To tackle your problem, had you considered making a MANUAL workflow
> rule for CONTACT that sets each address1_xxx field to the parent
> account's address field? Then, after updating the parent account's
> address you could call this on all their child contacts. This would
> potentially save you a lot of time, plus allow you to exclude from
> updating those inevitable exceptions for homeworkers etc.
>
> -Chris
> mscrm4u.blogspot.com
>

Re: Improve Address Functionality by MS

MS
Fri Jan 25 13:49:02 CST 2008

You could create a Custom Workflow Activity (or an Asynchronous Plugin for
that matter) that is triggered whenever you update the account's address. It
can then check if the account's contacts had the original address. If they
did, it can update them with the new address.

Michael

"Marge" wrote:

> No - we have contacts with additional addresses, not necessarily the same as
> the account address, and sometimes 30 or more addresses for the account.
> Thanks for the suggestion, but it relies on a manual process - prone to
> error. I still think there is a more elegant solution if we can create
> additional relationships with the address entity, or even bulk edit the
> address
> --
> Marge in the uk
>
>
> "ChrisC" wrote:
>
> > From your post I guess that in your business all contacts for an
> > account have the same address as the parent account? Yes, the way
> > MSCRM works creates lots of empty address spaces but ultimately it is
> > more flexible.
> >
> > To tackle your problem, had you considered making a MANUAL workflow
> > rule for CONTACT that sets each address1_xxx field to the parent
> > account's address field? Then, after updating the parent account's
> > address you could call this on all their child contacts. This would
> > potentially save you a lot of time, plus allow you to exclude from
> > updating those inevitable exceptions for homeworkers etc.
> >
> > -Chris
> > mscrm4u.blogspot.com
> >

Re: Improve Address Functionality by DanStein

DanStein
Thu May 08 15:43:01 CDT 2008

We have built a custom application that allows if a address location changes
it can roll down to all of the contacts. If you would like more information
you can let me know.
dstein@salesmetrix.net.

"MS" wrote:

> You could create a Custom Workflow Activity (or an Asynchronous Plugin for
> that matter) that is triggered whenever you update the account's address. It
> can then check if the account's contacts had the original address. If they
> did, it can update them with the new address.
>
> Michael
>
> "Marge" wrote:
>
> > No - we have contacts with additional addresses, not necessarily the same as
> > the account address, and sometimes 30 or more addresses for the account.
> > Thanks for the suggestion, but it relies on a manual process - prone to
> > error. I still think there is a more elegant solution if we can create
> > additional relationships with the address entity, or even bulk edit the
> > address
> > --
> > Marge in the uk
> >
> >
> > "ChrisC" wrote:
> >
> > > From your post I guess that in your business all contacts for an
> > > account have the same address as the parent account? Yes, the way
> > > MSCRM works creates lots of empty address spaces but ultimately it is
> > > more flexible.
> > >
> > > To tackle your problem, had you considered making a MANUAL workflow
> > > rule for CONTACT that sets each address1_xxx field to the parent
> > > account's address field? Then, after updating the parent account's
> > > address you could call this on all their child contacts. This would
> > > potentially save you a lot of time, plus allow you to exclude from
> > > updating those inevitable exceptions for homeworkers etc.
> > >
> > > -Chris
> > > mscrm4u.blogspot.com
> > >