Build curriculum plans in Salesforce, on the data already in your org.
Courses come from the catalogue you already keep, instructors from your people records. Add a position and a quantity, and each line prices itself from your own rate cards. Compare scenarios before you commit to one.
- Your data never moves. Records are created and kept in the org you already run. PlanFoundry installs alongside Education Data Architecture, not connected to it from outside.
- Your permissions still decide who sees what. Every record follows the sharing rules and field-level security you already have.
- Nothing leaves the boundary. No outside endpoints, no telemetry, no copy of your data anywhere else.
A recreation of a Salesforce Lightning record page, "M.S. Data Science — AY 2026–27", pending the dean's approval. The budget summary below is interactive and is exposed to assistive technology; the surrounding Lightning chrome is decorative and hidden from it.
Bucket detail shown for the baseline plan.
Try it: switch the scenario in the panel and every total recalculates.
Recreation of the product UI. Figures are real and reconcile; this page is not a live instance.
The problem this replaces
The department's spreadsheet said one number. The budget office's report said another.
Departments plan next year's teaching in spreadsheets. The budget office reconciles them by hand, against a system that builds its totals in several separate places. Every one of those places is somewhere two numbers can drift apart. Drift is always found late.
PlanFoundry removes the chance to drift. A total has one place it could have come from, because there is one calculation. Underneath it, the courses, staffing, funding and approvals are related records — not tabs in a workbook.
Who it's for
Three people have to trust the same number.
They ask about it differently. The plan is one record, so all three are looking at the same thing.
See every department's ask against its allocation, in one view. When a total is questioned, you can follow it down to the instructor and section it came from. What you approve is captured permanently, the moment you approve it.
Lay out next year's courses and staff them. A course nobody has staffed is visible rather than missing, costs appear as you type, and you can try a leaner version without touching the plan of record.
A managed package you install from a version ID. Private by default, field-level security enforced rather than assumed, three permission sets, and no outbound callouts to review. It reuses EDA's terms and courses instead of duplicating them.
Totals that cannot disagree
Your planning grid and your budget report cannot disagree, because there is only one number.
It is one field in your own org, computed once. The plan grid, the budget report and the record page all read it. None of them keeps its own copy, so there is nothing to fall out of sync.
One field, read in three places
Same field. Three screens. One number, because there is only one to disagree with.
Walk it down
One instructor on one section, followed up to the dean's decision.
-
One cost line$32,640
A. Ferreira, section 001 of DS 5100. Temporary Faculty at $96,000 annual × 0.34 FTE. The rate comes from the institution's own card, not a number typed into the plan.
-
Its course$130,760
DS 5100 across three sections: three faculty lines at $32,640, one teaching assistant at $28,000, one reader at $4,840.
32,640 × 3 + 28,000 + 4,840 = 130,760
-
Its role bucket$684,480
Every Temporary Faculty line in the plan, 7.13 FTE of it. This is the lens a dean reads first: not which course, but which kind of labour.
81.4% of the plan
-
The whole plan$840,850
Four buckets, nine courses, twenty-three sections. The same field the plan grid, the budget report and the record page all read.
684,480 + 126,000 + 20,680 + 9,690 = 840,850
-
The decision$27,150 under
Against an $868,000 allocation. The dean approves a number whose provenance runs all the way back down to one instructor on one section.
868,000 − 840,850 = 27,150
The model underneath
A plan is not a document. It is records that know about each other.
That is why one total can be computed once and read everywhere. Select any part to see what it touches.
Click any concept below to trace what it connects to.
Reused from the org you already run
PlanFoundry does not create these. Your departments, people, academic calendar and course catalogue stay the single copy they already are.
What a plan prices from
Your own reference data, dated by academic year. Change a rate here and every plan for that year reprices. Nobody re-keys a number.
The plan itself
One department, one academic year, and everything under it. This is what the planning grid edits — the four ideas that carry the rest.
Approval
Built when the plan is submitted, not stored in advance. Re-submitting rebuilds the route, so a change of approver takes effect.
The permanent record
What the plan looked like when it mattered: submitted, approved, finalized. Written once and never recalculated, so later edits cannot rewrite it.
After approval
Money that moves once the plan is settled, and what each person is committed to once every department is counted together.
Set once, read everywhere
Configuration sits outside the plan, which is why it draws no lines here. Every screen reads it.
Selected
Curriculum plan
One department, one academic year. It is the unit of approval, the thing an approver acts on, and where every total in the system lands.
Touches Department · Term & year · Course line · Staffing line · Funding line · Guideline · Approval stage · Exception · Snapshot
Nothing here is a copy. Each record exists once, in your org, and everything else points at it. That is why two screens can never hold two versions of the same number.