function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
NCMIAMINCMIAMI 

Help conditionally displaying a section with custom fields

I have custom membership data for my website subscribers. I've created a new section under the contacts tab named "Membership Information" which lists the unique ID and other custom membership specific fields.

 

However, I do not want this section to display if the Unique ID IsNull or empty. Is there a way to set-up this type of condition in salesforce?

Best Answer chosen by Admin (Salesforce Developers) 
MarkSilberMarkSilber

You could do some of this with record types and page layouts. When you update the data via the API, if you are populating the key fields, then you would also change the record type. You then need 2 screens -- one that has the extra fields and one that doesn't. Since users shouldn't be creating Contacts that have the information that is populated via the API, you should setup normal users profiles to not have access to the 2nd record type.

 

You can either have your API change the record type -- or an even easier solution is a workflow rule that flips the record type if certain fields are populated and flips it back if they aren't.

All Answers

JakesterJakester
Not without a lot of work using Visualforce. You can create validation rules that don't let users edit fields based on the Unique ID, but dynamic hiding/showing of fields can't be done easily.
NCMIAMINCMIAMI

Wow, that's disappointing. So basically I have to display a bunch of non-relevant, blank fields for every contact record in my database just for the benefit of a few?

 

Is there a different way to go about this - a work around or creative use of SF that I haven't thought of.

 

Basically, 15% of my records have login details and subscription details for my website. This data will be synchronized against my backend SQL database using the API so that SF users can view and edit the data without having to login to the admin section of our website.

 

So, I need this information fo rthose types of records, but not for records that don't have a corresponding account in my backend database.

 

Any suggestions for a different approach?

MarkSilberMarkSilber

You could do some of this with record types and page layouts. When you update the data via the API, if you are populating the key fields, then you would also change the record type. You then need 2 screens -- one that has the extra fields and one that doesn't. Since users shouldn't be creating Contacts that have the information that is populated via the API, you should setup normal users profiles to not have access to the 2nd record type.

 

You can either have your API change the record type -- or an even easier solution is a workflow rule that flips the record type if certain fields are populated and flips it back if they aren't.

This was selected as the best answer
NCMIAMINCMIAMI

Thank you Mark. I have the 2 screens already - one with the membership data and one without. I would just have to create the "Member" record type. 

 

Can users have access to 2nd record type only if exists but not have access to create a record from that 2nd record type? I also wonder if the API can push and pull data so that if someone calls in and we manually set-up a subscription - using the 2nd rec type - that the data is pushed to the SQL database. This is, of course, more advanced and would be saved for a later roll-out but I wonder if that is possible.

 

Thanks again.

 

NC

MarkSilberMarkSilber

When configuring Profiles, you can select which Record Types they have access to. The Profile configuration only controls what types of records they can create, not what they can see, so this would work in your use case.

 

I'm not sure how you have connected your SQL database and Salesforce, but if you had a web service that could be called by Salesforce, you could setup an Outbound Message workflow rule to push the data when it changes. As a less sophisticated method, you could create a field that gets flagged when the member data changes and then "pull" only those records to update your SQL database on a scheduled basis.

 

 

NCMIAMINCMIAMI
Thank You Mark. I'm still in the research & planning phase so nothing has been set-up yet. There are so many ways to acomplish the same thing in SF that I'm investing alot of time in the R&D phase. We'll probably be using web services so this is good to know. Thanks again for all of your insight. I really appreciate it.
JakesterJakester
Mark's advice is excellent - I'll just add that while Profiles don't control which RTs you can see, they can control which fields you can see, regardless of RT.