primary Role on party

[Hans Bakker]

In the SFA application I need the definition of a 'primary roleType' to
identify where a party is listed...either in leads, contacts or
accounts...

Anybody any objections when i add this field to the Party entity?

Regards,
Hans

[Adrian Crum-2]

Why not make it a party relationship? A party is related to this party/company/etc as a lead/contact/account/etc.

-Adrian

--- On Thu, 6/5/08, Hans Bakker <[hidden email]> wrote:
From: Hans Bakker <[hidden email]>
Subject: primary Role on party
To: "user" <[hidden email]>
Date: Thursday, June 5, 2008, 8:08 PM

In the SFA application I need the definition of a 'primary roleType' to
identify where a party is listed...either in leads, contacts or
accounts...

Anybody any objections when i add this field to the Party entity?

Regards,
Hans


     

[David E Jones]

I don't really like the idea of "primary role", as roles don't really  
work that way.

If you don't want a party showing up on a list of leads and contacts,  
then they shouldn't have both the lead and contact roles...

Could you be more specific about what you're trying to do here?

-David


On Jun 5, 2008, at 9:49 PM, Adrian Crum wrote:

> Why not make it a party relationship? A party is related to this  
> party/company/etc as a lead/contact/account/etc.
>
> -Adrian
>
> --- On Thu, 6/5/08, Hans Bakker <[hidden email]>  
> wrote:
> From: Hans Bakker <[hidden email]>
> Subject: primary Role on party
> To: "user" <[hidden email]>
> Date: Thursday, June 5, 2008, 8:08 PM
>
> In the SFA application I need the definition of a 'primary roleType'  
> to
> identify where a party is listed...either in leads, contacts or
> accounts...
>
> Anybody any objections when i add this field to the Party entity?
>
> Regards,
> Hans
>
>

[Hans Bakker]

Ok some more info.

In the SFA application i want to be sure a party is only listed in
either lead or contact or account and not in two lists. This is
independent of any relation

If i create party as a lead then i use this in the partyrelationship
entity to have a related partyGroup record for the company name.
When i covert the lead to contact I set the enddate on this relationship
to keep the history and create a new one for the role 'contact';
Before that i add the role of 'contact' to this party to indicate the
conversion. I can however not delete the 'lead' role because it is used
in partyrelationship.

having a new field on party is a very simple solution and i can change
the partyFind service with no effort so one can search on this field.

we can also consider to add a 'from/thru' date to the partyrole entity
however that is a pretty big change to the system because this entity is
used in many places.....


On Thu, 2008-06-05 at 21:59 -0600, David E Jones wrote:

>
> I don't really like the idea of "primary role", as roles don't really  
> work that way.
>
> If you don't want a party showing up on a list of leads and contacts,  
> then they shouldn't have both the lead and contact roles...
>
> Could you be more specific about what you're trying to do here?
>
> -David
>
>
> On Jun 5, 2008, at 9:49 PM, Adrian Crum wrote:
>
> > Why not make it a party relationship? A party is related to this  
> > party/company/etc as a lead/contact/account/etc.
> >
> > -Adrian
> >
> > --- On Thu, 6/5/08, Hans Bakker <[hidden email]>  
> > wrote:
> > From: Hans Bakker <[hidden email]>
> > Subject: primary Role on party
> > To: "user" <[hidden email]>
> > Date: Thursday, June 5, 2008, 8:08 PM
> >
> > In the SFA application I need the definition of a 'primary roleType'  
> > to
> > identify where a party is listed...either in leads, contacts or
> > accounts...
> >
> > Anybody any objections when i add this field to the Party entity?
> >
> > Regards,
> > Hans
> >
> >
>

[Adrian Crum-2]

Then that would put an arbitrary restriction on roles. A party could be both a lead and a contact.

-Adrian

--- On Thu, 6/5/08, David E Jones <[hidden email]> wrote:
From: David E Jones <[hidden email]>
Subject: Re: primary Role on party
To: [hidden email]
Date: Thursday, June 5, 2008, 8:59 PM

I don't really like the idea of "primary role", as roles don't
really  
work that way.

If you don't want a party showing up on a list of leads and contacts,  
then they shouldn't have both the lead and contact roles...

Could you be more specific about what you're trying to do here?

-David


On Jun 5, 2008, at 9:49 PM, Adrian Crum wrote:

> Why not make it a party relationship? A party is related to this  
> party/company/etc as a lead/contact/account/etc.
>
> -Adrian
>
> --- On Thu, 6/5/08, Hans Bakker <[hidden email]>
 
> wrote:
> From: Hans Bakker <[hidden email]>
> Subject: primary Role on party
> To: "user" <[hidden email]>
> Date: Thursday, June 5, 2008, 8:08 PM
>
> In the SFA application I need the definition of a 'primary
roleType'  
> to
> identify where a party is listed...either in leads, contacts or
> accounts...
>
> Anybody any objections when i add this field to the Party entity?
>
> Regards,
> Hans
>
>


     

[David E Jones]

Which is why I asked what Hans is really trying to accomplish.

I didn't say anything about a party not being able to be both a lead  
and a contact, just trying to figure out why he wants to distinguish  
them.

If it is a standard sales prospect progression then parties in each  
step would pretty much always be in the previous step as well, meaning  
if you want those that are in a certain step but not in the next step,  
you have to explicitly exclude those in the next step.

Still, the last paragraph is a guess and Hans would have to be more  
specific about what he's trying to do.

-David



On Jun 5, 2008, at 10:35 PM, Adrian Crum wrote:

> Then that would put an arbitrary restriction on roles. A party could  
> be both a lead and a contact.
>
> -Adrian
>
> --- On Thu, 6/5/08, David E Jones <[hidden email]>  
> wrote:
> From: David E Jones <[hidden email]>
> Subject: Re: primary Role on party
> To: [hidden email]
> Date: Thursday, June 5, 2008, 8:59 PM
>
> I don't really like the idea of "primary role", as roles don't
> really
> work that way.
>
> If you don't want a party showing up on a list of leads and contacts,
> then they shouldn't have both the lead and contact roles...
>
> Could you be more specific about what you're trying to do here?
>
> -David
>
>
> On Jun 5, 2008, at 9:49 PM, Adrian Crum wrote:
>
> > Why not make it a party relationship? A party is related to this
> > party/company/etc as a lead/contact/account/etc.
> >
> > -Adrian
> >
> > --- On Thu, 6/5/08, Hans Bakker <[hidden email]
> >
>
> > wrote:
> > From: Hans Bakker <[hidden email]>
> > Subject: primary Role on party
> > To: "user" <[hidden email]>
> > Date: Thursday, June 5, 2008, 8:08 PM
> >
> > In the SFA application I need the definition of a 'primary
> roleType'
> > to
> > identify where a party is listed...either in leads, contacts or
> > accounts...
> >
> > Anybody any objections when i add this field to the Party entity?
> >
> > Regards,
> > Hans
> >
> >
>
>

[Adrian Crum-2]

Umm...

> From: David E Jones <[hidden email]>
> Subject: Re: primary Role on party
> To: [hidden email]
> Date: Thursday, June 5, 2008, 8:59 PM
>
> I don't really like the idea of "primary role", as roles
don't
> really
> work that way.
>
> If you don't want a party showing up on a list of leads and contacts,
> then they shouldn't have both the lead and contact roles...

Anyways, the Data Model Resource Book provides an ideal model for multiple parties related to multiple parties in various roles. If you stay within those guidelines then you'll do well.

-Adrian

--- On Thu, 6/5/08, David E Jones <[hidden email]> wrote:
From: David E Jones <[hidden email]>
Subject: Re: primary Role on party
To: [hidden email]
Date: Thursday, June 5, 2008, 9:39 PM

Which is why I asked what Hans is really trying to accomplish.

I didn't say anything about a party not being able to be both a lead  
and a contact, just trying to figure out why he wants to distinguish  
them.

If it is a standard sales prospect progression then parties in each  
step would pretty much always be in the previous step as well, meaning  
if you want those that are in a certain step but not in the next step,  
you have to explicitly exclude those in the next step.

Still, the last paragraph is a guess and Hans would have to be more  
specific about what he's trying to do.

-David



On Jun 5, 2008, at 10:35 PM, Adrian Crum wrote:

> Then that would put an arbitrary restriction on roles. A party could  
> be both a lead and a contact.
>
> -Adrian
>
> --- On Thu, 6/5/08, David E Jones <[hidden email]>

> wrote:
> From: David E Jones <[hidden email]>
> Subject: Re: primary Role on party
> To: [hidden email]
> Date: Thursday, June 5, 2008, 8:59 PM
>
> I don't really like the idea of "primary role", as roles
don't
> really
> work that way.
>
> If you don't want a party showing up on a list of leads and contacts,
> then they shouldn't have both the lead and contact roles...
>
> Could you be more specific about what you're trying to do here?
>
> -David
>
>
> On Jun 5, 2008, at 9:49 PM, Adrian Crum wrote:
>
> > Why not make it a party relationship? A party is related to this
> > party/company/etc as a lead/contact/account/etc.
> >
> > -Adrian
> >
> > --- On Thu, 6/5/08, Hans Bakker
<[hidden email]
> >
>
> > wrote:
> > From: Hans Bakker
<[hidden email]>
> > Subject: primary Role on party
> > To: "user"
<[hidden email]>
> > Date: Thursday, June 5, 2008, 8:08 PM
> >
> > In the SFA application I need the definition of a 'primary
> roleType'
> > to
> > identify where a party is listed...either in leads, contacts or
> > accounts...
> >
> > Anybody any objections when i add this field to the Party entity?
> >
> > Regards,
> > Hans
> >
> >
>
>


     

[David E Jones]

On Jun 5, 2008, at 10:58 PM, Adrian Crum wrote:

> Umm...
>
> > From: David E Jones <[hidden email]>
> > Subject: Re: primary Role on party
> > To: [hidden email]
> > Date: Thursday, June 5, 2008, 8:59 PM
> >
> > I don't really like the idea of "primary role", as roles
> don't
> > really
> > work that way.
> >
> > If you don't want a party showing up on a list of leads and  
> contacts,
> > then they shouldn't have both the lead and contact roles...

I'm still happy to stick by that sentence and maintain that I didn't  
say anything about not allowing them to be in both roles.

> Anyways, the Data Model Resource Book provides an ideal model for  
> multiple parties related to multiple parties in various roles. If  
> you stay within those guidelines then you'll do well.

That could be what Hans is going for, but who knows. Maybe he does  
want them both to be associated with a certain company or sales  
person, but also there in both roles... then you have to do explicit  
exclusion anyway.

-David

> -Adrian
>
> --- On Thu, 6/5/08, David E Jones <[hidden email]>  
> wrote:
> From: David E Jones <[hidden email]>
> Subject: Re: primary Role on party
> To: [hidden email]
> Date: Thursday, June 5, 2008, 9:39 PM
>
> Which is why I asked what Hans is really trying to accomplish.
>
> I didn't say anything about a party not being able to be both a lead
> and a contact, just trying to figure out why he wants to distinguish
> them.
>
> If it is a standard sales prospect progression then parties in each
> step would pretty much always be in the previous step as well, meaning
> if you want those that are in a certain step but not in the next step,
> you have to explicitly exclude those in the next step.
>
> Still, the last paragraph is a guess and Hans would have to be more
> specific about what he's trying to do.
>
> -David
>
>
>
> On Jun 5, 2008, at 10:35 PM, Adrian Crum wrote:
>
> > Then that would put an arbitrary restriction on roles. A party  
> could
> > be both a lead and a contact.
> >
> > -Adrian
> >
> > --- On Thu, 6/5/08, David E Jones  
> <[hidden email]>
>
> > wrote:
> > From: David E Jones <[hidden email]>
> > Subject: Re: primary Role on party
> > To: [hidden email]
> > Date: Thursday, June 5, 2008, 8:59 PM
> >
> > I don't really like the idea of "primary role", as roles
> don't
> > really
> > work that way.
> >
> > If you don't want a party showing up on a list of leads and  
> contacts,
> > then they shouldn't have both the lead and contact roles...
> >
> > Could you be more specific about what you're trying to do here?
> >
> > -David
> >
> >
> > On Jun 5, 2008, at 9:49 PM, Adrian Crum wrote:
> >
> > > Why not make it a party relationship? A party is  
> related to this
> > > party/company/etc as a lead/contact/account/etc.
> > >
> > > -Adrian
> > >
> > > --- On Thu, 6/5/08, Hans Bakker
> <[hidden email]
> > >
> >
> > > wrote:
> > > From: Hans Bakker
> <[hidden email]>
> > > Subject: primary Role on party
> > > To: "user"
> <[hidden email]>
> > > Date: Thursday, June 5, 2008, 8:08 PM
> > >
> > > In the SFA application I need the definition of a  
> 'primary
> > roleType'
> > > to
> > > identify where a party is listed...either in leads,  
> contacts or
> > > accounts...
> > >
> > > Anybody any objections when i add this field to the  
> Party entity?
> > >
> > > Regards,
> > > Hans
> > >
> > >
> >
> >
>
>

[David E Jones]

It doesn't sound like the new field or the from/thru date are needed.  
Let me try to clarify what I wrote before about the explicit exclusion  
thing (ie when looking for leads include leads but exclude all of  
those who are also contacts, so that contacts don't show up with the  
leads).

You have a one-way progression among these roles, so you can define  
rules for viewing or reporting on them like:

1. if a party is in the contact role and the lead role include them on  
the contact list, but not on the lead list

In other words, just define a "lead" as only a lead and not a contact,  
ie the current role but not the "next" role, so that you only look at  
each in the furthest role down the line.

Any new data structures or whatever sound like they would be redundant  
and possibly confusing.

Looking at this particular situation realistically: when a party move  
from a lead to a contact, they ARE still a lead, but now they are also  
a contact. However, because they are a contact there is no reason to  
do anything with them to treat them as you would other leads.

-David


On Jun 5, 2008, at 10:28 PM, Hans Bakker wrote:

> Ok some more info.
>
> In the SFA application i want to be sure a party is only listed in
> either lead or contact or account and not in two lists. This is
> independent of any relation
>
> If i create party as a lead then i use this in the partyrelationship
> entity to have a related partyGroup record for the company name.
> When i covert the lead to contact I set the enddate on this  
> relationship
> to keep the history and create a new one for the role 'contact';
> Before that i add the role of 'contact' to this party to indicate the
> conversion. I can however not delete the 'lead' role because it is  
> used
> in partyrelationship.
>
> having a new field on party is a very simple solution and i can change
> the partyFind service with no effort so one can search on this field.
>
> we can also consider to add a 'from/thru' date to the partyrole entity
> however that is a pretty big change to the system because this  
> entity is
> used in many places.....
>
>
> On Thu, 2008-06-05 at 21:59 -0600, David E Jones wrote:
>>
>> I don't really like the idea of "primary role", as roles don't really
>> work that way.
>>
>> If you don't want a party showing up on a list of leads and contacts,
>> then they shouldn't have both the lead and contact roles...
>>
>> Could you be more specific about what you're trying to do here?
>>
>> -David
>>
>>
>> On Jun 5, 2008, at 9:49 PM, Adrian Crum wrote:
>>
>>> Why not make it a party relationship? A party is related to this
>>> party/company/etc as a lead/contact/account/etc.
>>>
>>> -Adrian
>>>
>>> --- On Thu, 6/5/08, Hans Bakker <[hidden email]>
>>> wrote:
>>> From: Hans Bakker <[hidden email]>
>>> Subject: primary Role on party
>>> To: "user" <[hidden email]>
>>> Date: Thursday, June 5, 2008, 8:08 PM
>>>
>>> In the SFA application I need the definition of a 'primary roleType'
>>> to
>>> identify where a party is listed...either in leads, contacts or
>>> accounts...
>>>
>>> Anybody any objections when i add this field to the Party entity?
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>
>

[Hans Bakker]

ok, i will put the extra constraint in the lead find and contact find
screens...

thanks for your help,

regards,
Hans


On Thu, 2008-06-05 at 23:50 -0600, David E Jones wrote:

>
> It doesn't sound like the new field or the from/thru date are needed.  
> Let me try to clarify what I wrote before about the explicit exclusion  
> thing (ie when looking for leads include leads but exclude all of  
> those who are also contacts, so that contacts don't show up with the  
> leads).
>
> You have a one-way progression among these roles, so you can define  
> rules for viewing or reporting on them like:
>
> 1. if a party is in the contact role and the lead role include them on  
> the contact list, but not on the lead list
>
> In other words, just define a "lead" as only a lead and not a contact,  
> ie the current role but not the "next" role, so that you only look at  
> each in the furthest role down the line.
>
> Any new data structures or whatever sound like they would be redundant  
> and possibly confusing.
>
> Looking at this particular situation realistically: when a party move  
> from a lead to a contact, they ARE still a lead, but now they are also  
> a contact. However, because they are a contact there is no reason to  
> do anything with them to treat them as you would other leads.
>
> -David
>
>
> On Jun 5, 2008, at 10:28 PM, Hans Bakker wrote:
>
> > Ok some more info.
> >
> > In the SFA application i want to be sure a party is only listed in
> > either lead or contact or account and not in two lists. This is
> > independent of any relation
> >
> > If i create party as a lead then i use this in the partyrelationship
> > entity to have a related partyGroup record for the company name.
> > When i covert the lead to contact I set the enddate on this  
> > relationship
> > to keep the history and create a new one for the role 'contact';
> > Before that i add the role of 'contact' to this party to indicate the
> > conversion. I can however not delete the 'lead' role because it is  
> > used
> > in partyrelationship.
> >
> > having a new field on party is a very simple solution and i can change
> > the partyFind service with no effort so one can search on this field.
> >
> > we can also consider to add a 'from/thru' date to the partyrole entity
> > however that is a pretty big change to the system because this  
> > entity is
> > used in many places.....
> >
> >
> > On Thu, 2008-06-05 at 21:59 -0600, David E Jones wrote:
> >>
> >> I don't really like the idea of "primary role", as roles don't really
> >> work that way.
> >>
> >> If you don't want a party showing up on a list of leads and contacts,
> >> then they shouldn't have both the lead and contact roles...
> >>
> >> Could you be more specific about what you're trying to do here?
> >>
> >> -David
> >>
> >>
> >> On Jun 5, 2008, at 9:49 PM, Adrian Crum wrote:
> >>
> >>> Why not make it a party relationship? A party is related to this
> >>> party/company/etc as a lead/contact/account/etc.
> >>>
> >>> -Adrian
> >>>
> >>> --- On Thu, 6/5/08, Hans Bakker <[hidden email]>
> >>> wrote:
> >>> From: Hans Bakker <[hidden email]>
> >>> Subject: primary Role on party
> >>> To: "user" <[hidden email]>
> >>> Date: Thursday, June 5, 2008, 8:08 PM
> >>>
> >>> In the SFA application I need the definition of a 'primary roleType'
> >>> to
> >>> identify where a party is listed...either in leads, contacts or
> >>> accounts...
> >>>
> >>> Anybody any objections when i add this field to the Party entity?
> >>>
> >>> Regards,
> >>> Hans
> >>>
> >>>
> >>
> >
>

[Adrian Crum]

David,

I sent that reply off in a rush as I was getting ready to go to bed.
Having looked at it again, it sounds kinda snobby. My apologies.

-Adrian

David E Jones wrote:

>
> On Jun 5, 2008, at 10:58 PM, Adrian Crum wrote:
>
>> Umm...
>>
>> > From: David E Jones <[hidden email]>
>> > Subject: Re: primary Role on party
>> > To: [hidden email]
>> > Date: Thursday, June 5, 2008, 8:59 PM
>> >
>> > I don't really like the idea of "primary role", as roles
>> don't
>> > really
>> > work that way.
>> >
>> > If you don't want a party showing up on a list of leads and
>> contacts,
>> > then they shouldn't have both the lead and contact roles...
>
> I'm still happy to stick by that sentence and maintain that I didn't say
> anything about not allowing them to be in both roles.
>
>> Anyways, the Data Model Resource Book provides an ideal model for
>> multiple parties related to multiple parties in various roles. If you
>> stay within those guidelines then you'll do well.
>
> That could be what Hans is going for, but who knows. Maybe he does want
> them both to be associated with a certain company or sales person, but
> also there in both roles... then you have to do explicit exclusion anyway.
>
> -David
>
>
>> -Adrian
>>
>> --- On Thu, 6/5/08, David E Jones <[hidden email]> wrote:
>> From: David E Jones <[hidden email]>
>> Subject: Re: primary Role on party
>> To: [hidden email]
>> Date: Thursday, June 5, 2008, 9:39 PM
>>
>> Which is why I asked what Hans is really trying to accomplish.
>>
>> I didn't say anything about a party not being able to be both a lead
>> and a contact, just trying to figure out why he wants to distinguish
>> them.
>>
>> If it is a standard sales prospect progression then parties in each
>> step would pretty much always be in the previous step as well, meaning
>> if you want those that are in a certain step but not in the next step,
>> you have to explicitly exclude those in the next step.
>>
>> Still, the last paragraph is a guess and Hans would have to be more
>> specific about what he's trying to do.
>>
>> -David
>>
>>
>>
>> On Jun 5, 2008, at 10:35 PM, Adrian Crum wrote:
>>
>> > Then that would put an arbitrary restriction on roles. A party could
>> > be both a lead and a contact.
>> >
>> > -Adrian
>> >
>> > --- On Thu, 6/5/08, David E Jones
>> <[hidden email]>
>>
>> > wrote:
>> > From: David E Jones <[hidden email]>
>> > Subject: Re: primary Role on party
>> > To: [hidden email]
>> > Date: Thursday, June 5, 2008, 8:59 PM
>> >
>> > I don't really like the idea of "primary role", as roles
>> don't
>> > really
>> > work that way.
>> >
>> > If you don't want a party showing up on a list of leads and
>> contacts,
>> > then they shouldn't have both the lead and contact roles...
>> >
>> > Could you be more specific about what you're trying to do here?
>> >
>> > -David
>> >
>> >
>> > On Jun 5, 2008, at 9:49 PM, Adrian Crum wrote:
>> >
>> > > Why not make it a party relationship? A party is related
>> to this
>> > > party/company/etc as a lead/contact/account/etc.
>> > >
>> > > -Adrian
>> > >
>> > > --- On Thu, 6/5/08, Hans Bakker
>> <[hidden email]
>> > >
>> >
>> > > wrote:
>> > > From: Hans Bakker
>> <[hidden email]>
>> > > Subject: primary Role on party
>> > > To: "user"
>> <[hidden email]>
>> > > Date: Thursday, June 5, 2008, 8:08 PM
>> > >
>> > > In the SFA application I need the definition of a 'primary
>> > roleType'
>> > > to
>> > > identify where a party is listed...either in leads,
>> contacts or
>> > > accounts...
>> > >
>> > > Anybody any objections when i add this field to the
>> Party entity?
>> > >
>> > > Regards,
>> > > Hans
>> > >
>> > >
>> >
>> >
>>
>>
>
>