I wanted to get an idea around what methodology other orgs have used for things like varying Detail pages based on Record Type. Typically everyone needs a general set of fields and then there are Record-Type specific fields in addition to those.
Our Opportunity detail page’s primary objects have 111 Fields for Opportunity, 74 for LineItems and we decided to combine everyone’s page into one using conditional rendering & enabling.
Whats the arguments against this methodology asides from marginally better page performance? Admittedly this page isn’t the fastest to load but would separating the pages based on record type really have that tremendous of an impact? Working with ~32 models right now some are for specific departments others are your standard “Key Contacts” and such.
Good question Erik. I’m not sure there’s one right answer, and it really depends on what level of shared stuff there is across record types and user profiles.
If you have ten record types, and each one only uses 20 of the 111 fields, loading 80 excess fields each time is probably not ideal, you might consider separate pages. But if there’s only 20 excess fields for a given record type then it’s probably not such a drain.
A couple of things to consider that might be a little out of the box:
Use page includes that render for specific record types or profiles, for example if some users/record types don’t need Key Contacts, you could put that on a page include that only renders as needed. Or even certain fields on the opportunity could be on RecordTypeAOpportunityInclude model on the page include. It will help your initial load time, but the Key Contacts would load a bit slower than if they were just included on the main load. Each way you might combine or break down separate pages or sections will have a speed benefits and drawbacks depending on the situation.
Another thing you might do is consider breaking each record type into a different model OppType1, OppType2, OppType3, etc. Don’t render any on page load except one OppMaster that has the record type name, then use an action sequence triggered on page load and branch actions to query only the model that corresponds to the right record type. This way you won’t even load the excess fields, and if you’re using Field Editors you don’t even need conditional rendering - the field editor won’t render if there are no rows in its model. However, any components used across all record types you’ll either need to duplicate or put those fields on OppMaster and tie the components to those.
At any rate, this is a good question and one you’ll probably keep asking and keep finding different answers to depending on the situation.
Erik,
Jack makes a good point about how many fields you load in addition to the number of models that you load. I’d recommend using page includes as much as you can. Each page include benefits you by only loading the XML and the Models when needed. Take related data (tasks, opplineitems, files) and put it on a separate tab that will load the page include for you. With Skuid 11, you can also unify the Save button using Event Triggered sequences (i.e. the oppdetail page issues a ‘Save’ event; each page include has a ‘Save’ event action sequence that responds to this event and saves any models on the page include).
As far as when to have separate pages versus a ‘one page for all’, I don’t think there is a clear ‘rule’ for that. I would say that looking at the usage may be helpful. If the data is close and the buttons or actions are similar, then a unified page makes sense. If the actions that each ‘record type group’ takes are different, then a separate page makes sense since you’ll be adding additional page XML to support actions that only some groups use.
Thanks,
Bill
Great suggestions all around, in the end 3 of our departments share similarities whereas one is drastically different than the other ones. We’ve decided a duality between opportunity detail pages is our best bet to reduce pageload and overall page management. Across all pages we will be incorporating page includes wherever possible to improve page performance.
As for the Event Triggering, I’ll have to test and see if there are any additional performance considerations using something like this. I’ve noticed our popup which populates a pricebook of 78 products has been behaving quite slow so this may be a possible solution to that.
