function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Bill WoodsonBill Woodson 

Are Record Types the right solution?

I need to create a contact model that allows a contact to be an account contact but also possibly a service provider.  So an account needs service, and a provider provides it.  Can I have a single contact that can both be an account contact in one context and be a provider in another?

Would I use record types for this?  account contact will have some custom fields that a provider won't and vice versa.  Any help is greatly appreciated.

Thanks.
Best Answer chosen by Bill Woodson
Balaji Chowdary GarapatiBalaji Chowdary Garapati
@Bill Woodson,

Then it is advisible to create a junction object between Account and Contact as "Provider" which also has look up to opportunity. Add all the provider related contact fields into the Provider object. No we will have a way to capture the additional provider information if he is a provider.

This can normalize the data that you are trying to store, as we will have all the provider information in one place, contact information at one place. Reporting also will be easier for eg., creating a report on all providers for a particular account and see what opportunities does he serve on, a simple report can be setup with a custom report type (Account-> Provider -> Opportunity) relaitonship, any contact field can be pulled to provider using a formula field. 

This model also serves like to be a provider, the person should be a contact first. You can add look up fiters to exclude the contacts from same account or opportunity account, which also satisfies your req, of contact doesnt necessarily to be a provider for same account & its opps itsself.

Having the data inputted again depends on how users like to navigate, based on which we can go for standard layout and a trigger which populate rest of look up fields or a visual force page/custom button  which prepoulates the account information when get trying to create a provider record from opportunity.

Hope you will like this solution.

Thanks,
Balaji
 

All Answers

Balaji Chowdary GarapatiBalaji Chowdary Garapati
@ Bill Woodson,

   Record type would support your model(having two different page layouts) but you will need to have two contact records, one with each record type to accomplish it. If you are try to have the same contact to be referred as a provider, you might need to have a custom field on contact that determines whether it is provider or not which also drives the validation rules that implies for  capturing  additional fields on contact. Actual implementation depends more on the business requirement of yours. For eg., if a contact acts as a provider for multiple accounts, then you might need to have a junciton object between account and contact that holds the information of the list of  providers for a particular account.

If you can elobarate your requirement, it helps in debating the best data-model to come up with!

Thanks,
Balaji
Bill WoodsonBill Woodson
Thanks for replying Balaji, No I would not want to create two records.  My goal would be that a single contact could both be an account contact and a provider.  In our case a provider could be an account contact for one or more accounts, they could also moonlight as a provider for one or more opportunities and I would not expect them to ever be a provider to an account they were also the contact for. I would want certain fields to only be attached to the contact if they were indicated as a provider that would not be necessary if they were only an account contact.  For that matter I would suspect that the opposite is true as well, there may be fields that are needed if they are an account contact that would not be necessary if the contact was only a provider.
Balaji Chowdary GarapatiBalaji Chowdary Garapati
@Bill Woodson,

Then it is advisible to create a junction object between Account and Contact as "Provider" which also has look up to opportunity. Add all the provider related contact fields into the Provider object. No we will have a way to capture the additional provider information if he is a provider.

This can normalize the data that you are trying to store, as we will have all the provider information in one place, contact information at one place. Reporting also will be easier for eg., creating a report on all providers for a particular account and see what opportunities does he serve on, a simple report can be setup with a custom report type (Account-> Provider -> Opportunity) relaitonship, any contact field can be pulled to provider using a formula field. 

This model also serves like to be a provider, the person should be a contact first. You can add look up fiters to exclude the contacts from same account or opportunity account, which also satisfies your req, of contact doesnt necessarily to be a provider for same account & its opps itsself.

Having the data inputted again depends on how users like to navigate, based on which we can go for standard layout and a trigger which populate rest of look up fields or a visual force page/custom button  which prepoulates the account information when get trying to create a provider record from opportunity.

Hope you will like this solution.

Thanks,
Balaji
 
This was selected as the best answer
Bill WoodsonBill Woodson
So if I understand the concept...

I would have three objects Account, Contact, and a junction object called Provider that can join the two together.  The provider object would contain all of the fields that only pertain to a contact acting as a provider.

Does that sound accurate?
Balaji Chowdary GarapatiBalaji Chowdary Garapati
Yes you got it!