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 <[EMAIL PROTECTED]>
wrote:
From: Hans Bakker <[EMAIL PROTECTED]>
Subject: primary Role on party
To: "user" <[email protected]>
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
