ElevateActual builds on standard Education Cloud objects whenever one fits and adds a custom object or field only with a written reason. Standard shapes survive upgrades, are what Agentforce and analytics expect, can be maintained by a campus admin, and are what Salesforce's Data Migration Kit targets. This page names the patterns we refuse and the exceptions we allow.
What Does Standard First Mean in Practice?
Standard first is a rule about where to look before you build. Education Cloud (Agentforce Education) ships standard objects for programs, courses, terms, offerings, participants, applications, decisions, holds, care plans, and gifts. Before anyone in our shop creates an object or a field, they search that reference for a standard one that already carries the data. If one exists, we use it, even when its label is not the word the institution uses. If none exists, the person proposing the custom object writes down what it holds, why no standard object holds it, and who will maintain it, and that note is reviewed before the field exists.
The rule applies to every Salesforce for higher education build we do, and it is stricter than most institutions expect. The custom field is always faster on day one. It is never faster on day four hundred.
Why Does a Custom Field Cost More Than It Looks?
The symptom shows up a year or two after go-live. A new release adds a feature the institution wants, and the feature does not see the institution's data. Each symptom has the same root cause: the data sits in a shape Salesforce did not anticipate. Four forces make that expensive.
- Upgrades. Salesforce adds fields and behavior to standard objects three times a year. The learning objects arrived in API version 57.0,
LearnerPathwayin 61.0, and theDroppedDateTimeandRegistrationDateTimefields onCourseOfferingParticipantin 64.0. Data on the standard object gets those improvements for free. A custom object gets nothing. - Agentforce and analytics expect standard shapes. The prebuilt agents Salesforce lists for Education Cloud on Salesforce Help, such as Course Search and Student Financials, read the standard objects. So do the Education Cloud dashboards and the Data 360 for Education mappings. A custom program table is invisible to all of them until someone builds custom actions, data streams, and reports, and then maintains them.
- Admins can maintain it. A campus admin who has taken the Education Cloud training recognizes
CourseOffering. They do not recognizeSection__c, and the consultant who named it has moved on. - The Data Migration Kit targets standard objects. Salesforce's kit for moving EDA, Admissions Connect, and Student Success Hub data into Education Cloud, described at Migrate Your Data to Education Cloud, maps into the standard model. Anything put elsewhere is outside the kit and becomes a hand-built migration the next time the institution moves.
The fix is the same in each case and cheaper before go-live than after: put the data where Salesforce expects it. The general rule: a custom object is a liability you choose to carry, so choose it on paper, with a reason, not in a sprint because the standard label looked unfamiliar.
Which Patterns Do We Keep Seeing?
Three patterns account for most of the custom metadata we are asked to inherit.
The Custom Enrollee Count
Symptom. A roster page shows a different number than the registration report. Someone added an enrolled-count field to the section record and a workflow that increments it. The workflow misses drops, so the field drifts.
Root cause. Nobody checked the object. CourseOffering already carries EnrolleeCount, EnrollmentCapacity, WaitlistCount, WaitlistCapacity, and AvailabilityStatus, maintained from the participant records.
Fix. Delete the field and the workflow, point the page and the report at the standard fields, and let AvailabilityStatus drive whether the storefront shows the section as open, waitlist, or closed.
Rule. Never duplicate a computed standard field. If the standard number is wrong, the participant records are wrong, and the fix is there.
The Custom Application Object
Symptom. An admissions office running on a custom Application__c cannot use the application review console, and cannot show applicants a checklist in a portal without custom code.
Root cause. The custom object was created in an earlier era, often inside a managed package, and nobody revisited it when IndividualApplication became the standard. The standard object comes with application timelines, decisions, and tasks, and the admissions features are built against it.
Fix. Migrate the application records to IndividualApplication with their timelines and decisions, retire the custom object, and rebuild the few truly local fields on the standard object, each with its reason recorded.
Rule. When Salesforce ships a standard object for a process you run, the process moves to it. A parallel custom object means maintaining two admissions systems.
The Custom Program Table
Symptom. A continuing education unit has a Program__c object with a Course__c child and a Section__c grandchild. It works until the institution wants learner pathways, agent course search, or a unified catalog with the credit side.
Root cause. The build predated the learning model, or the builder found Learning, LearningProgram, and LearningCourse confusing and reached for names that matched the spreadsheet. The standard chain is explained object by object in our walk through the Education Cloud data model for continuing education.
Fix. Map the custom hierarchy onto the standard one, migrate, and delete. In every case we have examined, the standard model had a place for every column in the custom one.
Rule. Unfamiliar names are not a reason to customize. Read the object reference until the names make sense, then build.
Temptation Versus What Already Exists
| Temptation | Standard object that already does it | When custom is justified |
|---|---|---|
| An enrollee count or seats-remaining field on the section | CourseOffering.EnrolleeCount, EnrollmentCapacity, AvailabilityStatus | Not for the count. Only for a figure the platform does not compute, such as a room's physical limit, with the reason written down. |
| A custom application object | IndividualApplication with its timelines, decisions, and tasks | When the thing tracked is not an application at all, such as a vendor intake form in the same org. |
| A custom program, course, or section table | LearningProgram, LearningCourse, CourseOffering, LearningProgramPlan | We have not found a case. |
| A CEU or units-earned field on the learner | CourseOfferingPtcpResult.UnitsEarned with DurationUnit set to Continuing Education Units | Not for the value. A formula or roll-up for display is acceptable; a typed-in total is not. |
| A custom product catalog for the storefront | Product2, ProductCategory, Pricebook2, PricebookEntry | Never the catalog. One custom lookup joining the variation product to its CourseOffering is justified, because no standard field makes that join for individual courses. |
| A custom external-ID field for the SIS key | None. Standard objects do not ship with a Banner, Colleague, or Jenzabar identifier. | Yes, the most common justified custom field we create: one external ID per integrated object, unique, named for the source system. |
Which Exceptions Do We Allow?
Standard first is a rule about where data lives, not a vow against code. Four kinds of custom work pass review without argument, because the platform provides the extension point and expects you to use it.
- A tax calculator extension. Salesforce Commerce exposes a tax extension point, and real per-line tax for a storefront that sells some taxable courses and some exempt ones is an Apex class against that interface. There is no declarative alternative.
- A payment adapter. Connecting the storefront to a campus payment processor such as Transact CashNet or TouchNet means a signed hosted-checkout handoff and a post-authorization adapter that writes the result back to the order. That is Apex by design. Salesforce Payments with Stripe needs no adapter, which is one reason to consider it.
- A storefront component. Lightning Web Components for the storefront's user interface, such as a section picker or a cart editor, are custom code that touches no data model. The standing rule across our builds is that the front end may be custom while record automation stays in Flow and Platform Events, as described in how we automate enrollment from checkout without Apex.
- Join and key fields. One custom lookup from the variation product to its
CourseOffering, and one external ID per object that an SIS or payment system keys on. Each has a one-line reason, and each would be on any architect's list.
Demonstration orgs are the other exception: a demo built to persuade a committee may carry customizations a production build would not, because its job is to be convincing by Thursday. Those do not travel into the delivered system, and our fixed-scope accelerators ship on the standard model with the exceptions above and nothing else.
What Is the General Rule?
Before creating any object or field, answer four questions in writing. What it holds. Which standard object was checked and why it does not fit. Who maintains it after go-live. What breaks if it is deleted. If the answers take a page, the standard object was probably right. The way we run a delivery builds this review into design sign-off, so the question is asked once, early. As of October 2026, each Education Cloud release has added fields and features to the standard objects, which is the strongest argument for standing on them.
Questions We Hear
Does standard first mean no custom fields at all?
No. It means no custom field without a reason that survives review. Our delivered orgs carry a few: external IDs for the SIS, a lookup joining a storefront product to its course offering, and the occasional local attribute no standard field covers. What we refuse is anything that duplicates a standard object or field.
Our managed package already has a custom application object. Do we have to move?
You do not have to. You should know what it costs. The admissions review console, the applicant portal components, the Education Cloud dashboards, and the recruitment agent are built against IndividualApplication. Our usual recommendation is to migrate at the point the package contract ends, when the institution is paying for a move anyway.
What if the standard object has the wrong label for our campus?
Rename the label. Salesforce lets an admin relabel standard objects and fields, so CourseOffering can display as Section and LearningProgram as Certificate without touching the API name. It is the usual fix for the vocabulary objection, and it takes an afternoon.
Do Agentforce agents really fail on custom objects?
They do not fail; they do not know the data exists. The prebuilt agents Salesforce lists on Salesforce Help ship with topics and actions that read standard objects. Data on a custom object is reachable only after someone builds custom actions for it and keeps them current with each release.
How do you enforce this during a build?
Every custom object or field is proposed with a written reason in the design record and reviewed before it is created, not after. Design sign-off includes a list of every custom field in the build with its reason beside it. A reviewer who cannot name the standard object they rejected does not get the field.