+ Start a Discussion
SteveEthosSteveEthos 

Lookup - Filtered by Record Type

I have been digging through the Boards, but I have not found the solution to this problem:

 

 

I am building a model that has many different type of "People":  (Doctors, Nurses, Pharmacists, Technicians).

 

It makes the most sense to make them all Contacts with different record types (they have the common fields, but also record type specific fields).

 

I have custom objects that need links to specific Record Types.  For example, I have a Nursing visit object that needs a link to the Nurse.  

 

However, when I use the native lookup, it shows all Contact records (Doctors, Pharmacists, etc).   This is not acceptable.  

 

If I have a "Current Physician" field, I cannot allow them to put a Pharmacist in that field.

 

I have found no way to lock lookups down by record type.  

 

My only solution is to create custom objects.  However, this seems like such a waste of the Contact object and Record Types.

 

Any solutions?

Thanks,

Steve 

werewolfwerewolf
You can't presently modify the lookups, although that is a highly-rated idea under consideration.
SteveEthosSteveEthos

Here is an update of where we are heading, let me know if anyone sees any problems/issues:

 

OPTIMAL: 

We would have loved to have used the Contact and Account objectsto represent key people/businesses in our system.  Here is the example:

 

People:  Pharmacists, Pharmacy Technician, Doctors, Nurses,Internal Employees, Referral Employees (Insurance companies)

Business:  Hospitals, Medical Groups, Pharmacies, InsuranceCompanies, Nursing Agencies, etc

 

It would have been great to make each of these record types of Contactand Account, and then have separate page layouts and custom fields.

 

PROBLEMS:

 

Problem #1:  Lookup fields show all of theContact/Accounts. 

This means that when I want to link a “Visit” to a Doctor, theuser gets a list of all people.  This is not acceptable.  That meansthat the standard lookup control on both Page layouts and Visual Force pagescould not be used.  We would have to develop our own.

 

Problem #2: Tabs on Applications  

We have different “Apps” that each represent a different users’sview of the system.  Some users would need a Tab for “Nurses”, some for“Doctors”, and so on.  There are even cases where we would need a few ofthese tabs on the same app.   However, the “Contact” Tab can only beadded to an APP once, and we can not have it show up with different identities(Nurses, Doctors, Pharmacists)

 

OPTIONS:

 

Option #1:  Pure Record Types, shared Accounts/Contacts

This is currently not a viable option due to the limitationsabove.

 

Option #2:  Pure Custom objects.

All of these objects would be custom SObjects.  This wouldsolve the problems above.  However, it would defeat a lot of the out thebox CRM functionality that would have been empowered by storing the data in theAccounts/Contacts.  Also, we would be duplicating a lot of data structuresand functionality that comes build in on the Account/Contactobjects.   We would be locked in to this and not be able to changewithout significant modifications to the data model.

 

Option #3:  Hybrid, light custom objects, links to Contact/Account

This would create light custom objects, that link to therespective Contact/Account objects.

 

·        The Lookups would work cleanly.

·        We can create Tabs for the custom objects.

·        To enable some of the nice features such as filtering that donot follow the reference field, we would add “Formula fields” to the customobjects that gave read only access to some of the fields on theAccount/Contact.

·        We would need to build Custom Visual Force pages for theobjects, (one for view, one for new/edit).  These would handle the linkingto the Account/Contact. 

·        I am designing shared Components for Acccount and Contact fieldsthat can be placed on the custom View/Edit pages.  This way we would onlyneed to maintain the layouts (in the Component) in a couple of places, and havethe encapsulating pages (Nurse, Doctor, Pharmacist), contain the components,and just add the extra fields (nursing only, for example)

·        This would limit the use to standard, Force.com page layouts,instead we would utilize Visual Force.

 

I am still pondering where toput the “custom fields” for each area (Nursing fields, Pharmacy fields, Doctorfields).  They make most sense on the Custom objects.  However, downthe road if Force.com enhances the use of Account/Contact, then these would needto be moved.

 

We may still want to add ourown custom Lookups if we want to have our own filtering (only show Nurses thatare in the area (state, city, or attached to some office).  This wouldhave been a great set of functionality to add to Force.com.

  

If anyone has tried something similar, let me know how it worked out.

 

Steve 

Ron HessRon Hess

Sounds like an interesting solution to the missing feature (filtered lookups), i can see how it would work.

 

for this : I am still pondering where toput the “custom fields” for each area (Nursing fields, Pharmacy fields, Doctorfields).  They make most sense on the Custom objects.  However, downthe road if Force.com enhances the use of Account/Contact, then these would needto be moved.

 

 

did you consider the <apex: detail > component, i believe this observes the record types?

if given that, the option #3 + record types is also a clean solution.

 your VF page could pull all the contact details using just that one tag (apex: detail subject=id).

and if that works,

 

then your custom fields go on the contact, and you take advantage of page layouts.