I85PREP
⌘ K
Platform App Builder study materials
Platform App Builder study resources

One Record Page, Three Record Types, Four Seconds

Platform App Builder · Put your knowledge to work in context.

All case studies

One Record Page, Three Record Types, Four Seconds

Brightline Retail's Opportunity record page has three record types (New Business, Renewal, Partner) and one Lightning record page assigned to all of them and to every profile. The page carries 85 fields across six sections, five related lists, and two legacy Visualforce pages embedded as custom components. Reps complain they scroll three screens to reach the four fields they use most, and the page takes about four seconds to render. Leadership wants the four key fields pinned at the top, a Contract Renewal section that appears only for Renewal opportunities whose Contract_End_Date__c falls within 90 days, and margin fields hidden entirely on Partner opportunities. The team has no developer and no AppExchange budget, and some reps work offline in the mobile app.

1. Which declarative mechanism do you use for the field-level requirements, and what constrains the choice?

Read the worked answer

Dynamic Forms, delivered through the Lightning record page, not a page-layout redesign.

  • Add a Dynamic Forms component at the top of the page containing only the four key fields. That satisfies 'pinned at the top' without a custom component.
  • Each field and section in Dynamic Forms can have its own visibility rule, so the Contract Renewal section and the margin fields are handled by filters rather than by three separate pages.
  • Constraints you must design around:
    • The object must be supported by Dynamic Forms; confirm before promising anything. Most standard and custom objects are, but verify.
    • Migration from the page layout is effectively a one-way move for the migrated sections - do it in a sandbox, look at it, and only then do it upstream.
    • Because each record page is assigned per app, per record type and per profile, 'one page for all types' works, but if a future profile needs a different page you are back to assignments. Prefer visibility filters on one page.
  • The related lists are unaffected by Dynamic Forms; they stay on the page and stay part of the load time.

A record-type-specific page layout cannot express 'within 90 days of today' at all, which is why layout alone cannot meet the brief.

2. Two filters cannot be expressed with plain field comparisons: 'Renewal type' and 'within 90 days of today'. How do you build them?

Read the worked answer

Move the logic into formula fields, then filter on a Boolean.

  • Renewal_Window__c (Formula, Checkbox): AND(RecordType.DeveloperName = 'Renewal', NOT(ISBLANK(Contract_End_Date__c)), Contract_End_Date__c <= TODAY() + 90, Contract_End_Date__c >= TODAY())
  • Is_Partner__c (Formula, Checkbox): RecordType.DeveloperName = 'Partner'
  • Then set component visibility on the section and fields to Renewal_Window__c = True and Is_Partner__c = False.

Why this shape:

  • Visibility filters are reliable for equality and simple comparisons on a single field. Relative date logic ('next 90 days') is not something to trust a filter with - a checkbox makes the intent readable to the next admin and testable in a report.
  • Record type is not always exposed as a selectable filter in every context; a formula checkbox removes the doubt.
  • The formula evaluates on page render, which is exactly when the decision needs making. It does not change data and does not need a batch job.
  • Test it by opening one opportunity of each type with dates at −1, +1, +89 and +91 days from today. Formula boundaries are where this breaks.

3. The four-second render and the offline complaint - what do you attack, and what do you tell the business you cannot fix declaratively?

Read the worked answer

Performance:

  • The page is doing too much. 85 fields, five related lists and two Visualforce components all load in the same request. Removing fields alone is not enough; trim the related lists to the two reps actually use and mark the rest as a link or a separate tab.
  • The two embedded Visualforce components are the most likely culprits and the least visible to the admin. Check whether either makes a callout or a large SOQL query on load. If they can be replaced by a standard component or a related list, do that.
  • Measure before and after with the browser's network panel, not by asking reps whether it feels faster.

Offline on mobile:

  • Dynamic Forms and visibility filters behave correctly in the Salesforce mobile app. That part is safe.
  • Embedded Visualforce and many custom Lightning components are not available offline. Anything the reps need offline must be standard fields, standard related lists, or a component explicitly built for offline - which is a developer and budget conversation, not a declarative one.
  • Say that plainly to the business: 'the page layout work is ours and finishes this sprint; offline availability of the two custom panels is a development request.' Promising both and delivering one is how admins lose credibility.