Custom Metadata Types vs Custom Settings vs Custom Labels 💬 In plain words: Three lookalikes: Custom Metadata = configuration that DEPLOYS with your code (best for app settings). Custom Settings = org/user-specific values, changeable at runtime (hierarchy type is great for bypass switches). Custom Labels = translatable text for the UI. 📌 Example: API endpoint URLs per environment → Custom Metadata (deploys with code, sandbox vs prod values). A 'Bypass_Automation__c' checkbox an admin flips during data load → hierarchy Custom Setting. The word 'Submit' translated to Hindi → Custom Label. 🎬 Real-Life Example: The Fee Table Trapped Inside Code Skyline charges a different delivery fee per city. Apex needs those rates on every booking. The Old/Bad Way: if (city == 'Delhi') fee = 50. Else if (city == 'Mumbai') fee = 65. … Every rate change is a code change, a test run, and a deployment. Why this is bad: Business data is trappe...
Reports, Dashboards & Analytics Architecture
💬 In plain
words: Reports are questions
you ask of your data; report types decide which objects a report is even
allowed to ask about; dashboards show many answers on one screen. Key trap: who
a dashboard 'runs as' decides whose data everyone sees.
📌 Example: The VP's dashboard shows 40 deals; a rep opens
the same dashboard and sees 12. Check 'view dashboard as': it runs as the
viewer, and the rep's sharing only reaches 12 opportunities. Same report,
different eyes.
Concept
Reporting starts with Report Types. A report type decides which objects and fields are reportable, and whether the join is inner or outer, that is the 'with or without related records' choice. It is the most under-appreciated lever on the platform. Custom report types unlock cross-object paths and relationships that are otherwise hidden. Reporting snapshots capture data at a point in time into a custom object, which is how you trend. Dashboards have a running user, and who that user is decides whose data you see, so it is a security decision. At LDV, reports hit row limits and time out, covered in 10.6, which pushes you to CRM Analytics (Tableau CRM) or an external BI tool. External objects report only in a constrained way.
🧠Report TYPE
decides what's reportable (with/without related = inner/outer join). Snapshot =
trend over time. Dashboard running-user = whose data + security.
Core Q&A
Q: Users say a report is
'missing' records that clearly exist. Most likely causes?
🎯
Say this first: It's almost always visibility: sharing,
the report type's join (inner join drops records), filters, or the running
user's FLS.
A: Work
down this list in order. One: the report type's join. If it says
'Accounts WITH Contacts', every account with no contact disappears. Switch to
'with or without'. Two: report filters — date ranges, 'My' scope, status.
Three: sharing. The running user only sees records they have access to, covered
in 2.x. An admin sees more, so 'it works for me' proves nothing. Four: record
types or field-level visibility hiding the fields you filter on. Five: the
record type or the fields were never added to the report type at all. Check the
join and the running user's sharing before you conclude that data has been
lost.
Follow-ups (scenario-based)
Q1: A dashboard shows
different numbers to different users. Is that a bug?
A1: Usually
not, and it depends on the running user setting. A dynamic
dashboard runs as the viewing user, so each person sees data scoped to their
own sharing. That is what you want for a 'my team' dashboard. A static
dashboard runs as one fixed configured user, so everybody sees that user's
data. If leadership needs one consistent org-wide number, set a running user
with broad access. If reps should only see their own, dynamic is correct. The
'bug' is almost always a mismatch between the running-user mode and what the
business actually meant. Dynamic dashboards also carry per-org limits, which
are worth knowing.
Q2: Reports on a 50M-row
object time out. Options?