Curriculum planning and budgeting, inside your own Salesforce org.
A managed package, not an implementation project. Install it from a version ID, confirm a short set of settings against the data you already keep, and start planning. Courses come from your catalog, instructors from your people records, and every line prices itself from your own rate cards.
- 01Install
- 02Map your org data
- 03Start planning
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.
What it does
Your curriculum data is already in Salesforce. Put it to work.
-
01Pick the courses
From the catalog you already keep. Instructors come from your people records. Nothing is recreated, duplicated or kept in sync by hand.
-
02It prices itself
Add a position and a quantity, and the line prices from your own rate cards. Change a staffing assumption and the budget changes with it.
-
03Compare before you commit
Test a different course mix or staffing model as a scenario, and see what it costs against the plan of record before choosing one.
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.
How a plan moves
One department, one academic year, one route through approval.
A plan covers one department for one academic year. Course lines say what the department intends to offer. Staffing lines say who teaches it, and what that costs.
-
01
Draft
The department's working copy, visible only to the department. Until it is submitted, it is not a proposal.
-
02
Submitted
The route is built: one stage per approver the department has actually named. Any unpriced line has to be acknowledged first.
-
03
Approved
Every stage has acted, and a snapshot is captured. It is a complete record of what was approved, and later edits cannot rewrite it.
-
04
Finalized
Sixty days after the academic year ends, a nightly job takes a final snapshot and closes the plan.
The route this plan actually took
Screenshot: an approval stepper showing three completed stages. Program lead M. Okafor on July 6, Department chair D. Whitfield on July 9, and Budget analyst S. Reyes on July 15. The fourth stage, Dean, is currently pending.
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 reads your course catalog rather than keeping a second copy of it.
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
Specification
What it does, from the first course line to the approved budget.
Everything here is built and tested today. What each tier includes is on the pricing page.
The plan grid behind that total
A recreation of the Lightning plan grid. The table below is readable directly; DS 5100 can be expanded to show the five cost lines that sum to its total.
| Course | Units | Quarter | Sect. | Enroll | Planned Cost | Cost / Student |
|---|---|---|---|---|---|---|
| DS 5100Machine Learning Foundations | 4 | Fall | 3 | 140 | $130,760 | $934 |
|
Cost lines · 3 sections
001 · A. FerreiraTemporary Faculty · $96,000 annual × FTE0.34 FTE$32,640
002 · A. FerreiraTemporary Faculty · $96,000 annual × FTE0.34 FTE$32,640
003 · L. NovakTemporary Faculty · $96,000 annual × FTE0.34 FTE$32,640
All · J. ParkTeaching Assistant · $28,000 annual × FTE1.00 FTE$28,000
All · R. AdeyemiReader · $22/hr × hours220 hrs$4,840
5 cost lines · 3 sectionsCourse total $130,760
|
||||||
| ▸DS 5030Data Visualization | 3 | Fall | 2 | 84 | $51,080 | $608 |
| ▸STAT 5010Probability & Inference | 4 | Fall | 2 | 96 | $113,420 | $1,181 |
| ▸STAT 5210Statistical Computing | 4 | Winter | 4 | 152 | $161,320 | $1,061 |
| ▸DS 5200Deep Learning | 4 | Winter | 2 | 88 | $82,800 | $942 |
| ▸DS 5310Causal Inference for Policy | 3 | Winter | 1 | 34 | $25,710 | $756 |
| ▸DS 5420Data Ethics & Governance | 2 | Spring | 2 | 96 | $35,280 | $368 |
| ▸DS 5500Applied ML Practicum | 4 | Spring | 3 | 108 | $130,480 | $1,208 |
| ▸DS 5900Capstone Project | 6 | Spring | 4 | 118 | $110,000 | $932 |
| Fall $295,260 · Winter $269,830 · Spring $275,760 | $840,850 | |||||
Click the arrow beside DS 5100 to see the five cost lines behind its total.
- Build the plan and watch the cost as you type
- Route it through the approval chain you already have
- Totals that cannot disagree with each other
- See the whole department, and the whole institution
- Access controlled the way a university actually needs it
- Install and configure without an engineer on call
- Built to hold up as an institution grows into it
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 catalog 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.
Native to Salesforce
Nothing leaves your org.
PlanFoundry installs directly inside the Salesforce org your institution already runs and works alongside the education data model that org is built on. It is not a separate planning system connected to Salesforce from the outside: plans, scenarios, positions and calculations are created and maintained inside your existing environment, and the only trust boundary involved is the one you already have with Salesforce.
PlanFoundry creates and stores its records in your Salesforce org. There is no secondary database and no separate copy of your institutional data to reconcile or govern.
The permissions, sharing rules and field-level security configured in Salesforce continue to determine what each user can see and do. PlanFoundry does not introduce a second access model for your team to manage.
No external endpoints. No product telemetry. No shadow copy of your data stored somewhere else. Your curriculum plans stay inside the environment your institution already trusts.
No outbound callouts and no external services. Nothing PlanFoundry does sends data anywhere but tables in your own org.
PlanFoundry carries its own academic year and term records, so a plan is dated against your calendar whether the org runs Education Data Architecture, Education Cloud, or neither. Where one of those is present it reads from it instead of asking you to retype it. In development, not yet in the package
Org-wide defaults are Private on plans, ledgers, transfers and workload records. Access is computed and shared deliberately.
Every SOQL and DML statement declares an access level — user mode or system mode — chosen by how it is invoked rather than assumed from the sharing model.
CPS_Planner, CPS_Approver and CPS_Admin. A planner's permission set cannot see past its own department.
Lightning Experience only. This package ships no Visualforce and no Aura components.
Build. Price. Compare. Decide.
One place to answer the questions that shape a curriculum.
Academic and financial teams ask these in sequence, and today they answer them in different documents. The answers stay attached to the records behind them, so how a plan was built and what is driving its cost are both visible.
- 01Which courses are we planning to offer?
- 02Who and what will be needed to deliver them?
- 03What will the plan cost?
- 04How does one scenario compare with another?
- 05Which option best balances academic priorities and financial reality?
One system, one source of truth
Forge plans from the data you already trust.
PlanFoundry brings curriculum design and financial planning together without separating either from the institutional data underneath. Less time copying information, rebuilding calculations and reconciling versions. More time evaluating what your institution can actually deliver.
Common questions
What a procurement reader asks first.
- Does PlanFoundry run inside our own Salesforce org?
- Yes. Your records stay in your org, under your own sharing rules and field-level security. It is not an integration and not a sync. It is a managed package, installed from a version ID the same way any AppExchange product installs.
- Does it require Education Data Architecture?
- No. PlanFoundry carries its own academic year and term records, so it plans against your calendar whether the org runs Education Data Architecture, Education Cloud, or neither. Where one of those is present it reads from it rather than asking you to retype it. Framework-independent installation is in development and not yet in the released package.
- Does any of our data leave the org?
- No. Nothing PlanFoundry does sends data anywhere but tables in your own Salesforce org. There are no outbound callouts, no telemetry and no external services.
- How does approval routing work?
- It follows the chain you already use. Five role slots you name yourself, resolved per department, up to ten on Premium, and unlimited on Enterprise. You set the order, and a stage nobody has been named for is skipped rather than left blank. Each approver sees only the plans that are theirs to decide.
- What stops two screens from showing different totals?
- There is only one number for them to show. Every dollar figure is a native Salesforce rollup or formula field, computed once, and the planning grid, the budget report and the record page all read that same field. There is no second calculation to drift from the first.
- Is there a free tier, or only a trial?
- There is a genuinely free tier, and it is a destination rather than a trial. A single programme, a continuing-education division or a small college can run a real planning cycle on it: build the grid, see live costs, route through real approvers, and finish with a permanent record of what was approved.