Product

From a draft plan to an approved allocation, inside your own org.

Everything on this page is built and tested today.

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.

  1. 01

    Draft

    The department's working copy, visible only to the department. Until it is submitted, it is not a proposal.

  2. 02

    Submitted

    The route is built: one stage per approver the department has actually named. Any unpriced line has to be acknowledged first.

  3. 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.

  4. 04

    Finalized

    Sixty days after the academic year ends, a nightly job takes a final snapshot and closes the plan.

Returned at any stage sends the plan back to Draft. Re-submitting rebuilds the route, so an approver change made in the meantime takes effect.  ·  An approved plan can be submitted again as an Augmentation — asking for more after the fact. Approvers see it as one, not as a first pass.

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.


What's built today

What it does, from the first course line to the approved budget.

A row marked Starter+ or Premium names the lowest tier that includes it. The pricing page lays out what separates them.

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.

M.S. Data Science — AY 2026–27 · 9 courses · 23 sections
CourseUnitsQuarterSect.EnrollPlanned CostCost / Student
DS 5100Machine Learning Foundations4Fall3140$130,760$934
DS 5030Data Visualization3Fall284$51,080$608
STAT 5010Probability & Inference4Fall296$113,420$1,181
STAT 5210Statistical Computing4Winter4152$161,320$1,061
DS 5200Deep Learning4Winter288$82,800$942
DS 5310Causal Inference for Policy3Winter134$25,710$756
DS 5420Data Ethics & Governance2Spring296$35,280$368
DS 5500Applied ML Practicum4Spring3108$130,480$1,208
DS 5900Capstone Project6Spring4118$110,000$932
Fall $295,260 · Winter $269,830 · Spring $275,760$840,850

Exceptions an approver sees

Screenshot: three flagged exceptions on the plan. TA FTE above cap at $14,000, a faculty line held open at $24,000, and Reader hours above ratio at $4,180.

The instructor board

Screenshot: instructor workload cards. D. Whitfield is at capacity, 1.50 of 1.50 FTE. M. Chen has 0.14 FTE of room, at 0.84 of 1.50 FTE.

01Build the plan and watch the cost as you type

A planning workspace, not scattered tabs
Grid, approvals, portfolio, instructor board and setup live in one place, instead of separate pages someone has to remember to check.
Courses are the plan, not an afterthought
Every course the department might offer is a row, staffed or not. An unstaffed course is something you can see and fix, rather than something absent.
The cost shows up before you save
Type a quantity against a position and the rate resolves from your own rate cards, totalling as you go. Nobody re-keys numbers into a spreadsheet to find out what a plan costs.
An unpriced position is a flag, not a silent zero
A line with no rate for that position and year is flagged, not quietly totalled as free.
Instructor search starts with who's already on the plan
Assigning an instructor searches the people already on that plan, not every contact in the org. Searching wider is a deliberate step, and anyone found that way stays marked as one.
A conflict hint that stops at the boundary it should
Assigning someone already committed elsewhere says so at that moment — that a commitment exists, and nothing more. Not the department, not the plan, not the amount. Enough to ask the right question, not enough to see across a line you are not entitled to.
What-if planning that cannot touch the real plan
Copy a plan, change it, compare the two side by side, promote the one that wins. The plan of record is never at risk while you explore.
Starter+
Your bargaining-unit titles, not just ours
Import your own position and rate data from CSV. Every row is validated first, and the file loads completely or not at all — a half-loaded rate card does not fail loudly, it prices something at zero.
A rate card that arrives late leaves no stale lines behind
A batch job reprices any line left at zero because its rate card arrived after the plans did.
Buyout accounting is a setting, not a guess
Whether external funding on a buyout reduces the department's dollar ask is your institution's choice, with a per-line override for the genuine exception. The setting survives when a plan is copied forward.
Follows the institution's currency, not a hardcoded one
It reads your org's currency, and each user's own the moment Salesforce Multi-Currency is on. Nothing to configure separately.

02Route it through the approval chain you already have

Stages built from who your institution actually names
Not a fixed four-person chain. Five slots you name yourself, or ten on Premium — enough for a campus routing through school, division, budget office, senate and provost. A stage nobody has been named for is skipped, not left blank.
The order is yours to set
If your budget office signs off after the dean rather than before, reorder the slots. The router, the preview and the approver badges all read the same order, so a plan cannot preview one route and then take another.
Starter+
A queue for the people who approve, not just the people who plan
Each approver sees only what is theirs to decide. A plan with unpriced lines cannot reach them until those lines are acknowledged.
Caps evaluated automatically, not policed after the fact
Per-department caps are checked at submission. A plan over its cap is flagged for the approver to allow or deny, with the effect on the total shown as they decide.
Starter+
Approve a stack of plans in one action
A dean approves a queue in one action instead of clicking through plans one at a time. Each plan commits on its own, so one bad plan cannot roll back the good ones.
Starter+

03Totals that cannot disagree with each other

The screen, the report and the record page cannot disagree
Every dollar figure is a native rollup, computed once, and all three read the same field. There is no second, code-calculated version of the number to drift from it.
An immutable record of what was actually approved
Approving a plan freezes a snapshot, and a built-in check reconciles any live plan against any snapshot. That is what makes a cutover from an old system verifiable rather than hoped for.
Approved cost is on the record permanently, at every tier
Submit, approval and finalization each capture the approved cost permanently, with no way to purge it. Procurement asks this early; the answer is already here.
Lists are capped; money is not
Where a screen limits how many rows it shows, the totals above it still cover everything in scope. A shortened table can never quietly shrink the number that matters.
Tested like software that handles real budgets
Automated tests across the server logic and the interface run before any change ships. Regression tests are proven by breaking the fix on purpose and watching the test catch it.

04See the whole department, and the whole institution

Workload across a department, at a glance
Who is committed to what, with exact totals even when the list below them is capped for readability.
A dean's view and an analyst's view of the same data
Portfolio home, budget report, worksheet and cost-by-role. Allocation against planned cost, with no export step in between.
Starter+
Compare scenarios across a whole portfolio, not one plan at a time
Line up scenarios across every department in one view, instead of opening plans one after another. A comparison too large to hold is refused with an explanation, never silently trimmed.
Premium
Reports and dashboards that ship in the box
They read the same rollups the screens do, so there is no second reporting calculation to keep in sync.

05Access controlled the way a university actually needs it

Private by default
Plans, ledgers, transfers and workload records start private. Access is computed and granted deliberately, not left open and policed by habit.
Sharing computed from your own org chart
Each plan is shared with its department's actual approvers, and recalculated automatically when the department or owner changes.
A planner's permission set that cannot see past its own department
Everything a planner needs day to day — build, cost, submit — with no org-wide “see and edit everything” grant baked in.
Field-level security enforced, not assumed
Every user-facing query and write states the access level it runs under, rather than inheriting one from the sharing model and hoping.
Who can act on a plan changes with its status
The owner while it is a draft, the current approver once submitted, nobody once approved. Any bypass is an administrator grant that ships assigned to no one.

06Install and configure without an engineer on call

A real Salesforce managed package
Installed from a version ID like any AppExchange product, not a bundle of source that someone has to deploy by hand.
A guided setup wizard
Six steps: institution basics, the academic calendar, departments and approvers, positions and rate cards. Each one reports whether it is actually finished.
Historical plans, without a data migration project
Old plans load as queryable snapshot records, so the history is there to look at without migrating tens of thousands of transactional rows.
Premium
Documentation written for an administrator who has never seen the codebase
Install, configure, administer, and the concepts underneath. Every cross-reference is checked, so a link cannot quietly rot.

07Built to hold up as an institution grows into it

Every list has a ceiling, and every ceiling says so
Nothing degrades quietly. A capped screen says it is capped.
Bulk operations refuse a batch they cannot finish
They refuse before touching anything, rather than failing partway and leaving a half-done job behind.
The planning grid does not recompute what it already knows
Grouping and totals are cached, and thrown away only when something underneath actually changes.
Large grids render only what is on screen
With full keyboard navigation, so a department with hundreds of lines is not a slow page.
The cross-department instructor board is precomputed overnight
It only recalculates live if the cache goes stale. Rarely slow, never wrong.
Premium
Plan finalization runs in safe batches
Not one giant nightly job that can die quietly at scale.

Built natively on Salesforce

Nothing leaves your org.

The only trust boundary involved is the one you already have with Salesforce. PlanFoundry installs as a real second-generation managed package and stays inside it.

No telemetry

No outbound callouts and no external services. Nothing PlanFoundry does sends data anywhere but tables in your own org.

Built on EDA

PlanFoundry requires Education Data Architecture and reuses its term and course records rather than duplicating them. That decision is deliberate and permanent.

Private by default

Org-wide defaults are Private on plans, ledgers, transfers and workload records. Access is computed and shared deliberately.

Field-level security enforced

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.

Three permission sets

CPS_Planner, CPS_Approver and CPS_Admin. A planner's permission set cannot see past its own department.

Lightning only

Lightning Experience only. This package ships no Visualforce and no Aura components.

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?
Yes. PlanFoundry reuses EDA's term and course records rather than duplicating them. That decision is deliberate and permanent, so an institution already running EDA is the intended install.
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, or up to ten on Premium. 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.