Approve your first program charter

A charter is a program's mission, vision and scope, put in writing and signed off by someone above the site. In PTRS it is the only Programs workflow that runs from start to finish and leaves a correct, auditable record behind.

By the end of this tutorial you will have written a charter, sent it for approval, approved it, and read the approval history it produced.

Who can do this

• Site director
• Organisation admin
• Super admin

management for steps 1-2; admin for step 3

Steps 1 and 2 need the module-wide setting: a site director, an organisation administrator or a super admin.

Step 3 needs a second, narrower setting, and effectively an organisation administrator or a super admin only. A site director cannot approve, which is the point of the control. A regional director holds the setting but cannot reach the screen, see why.

Before you start

You need an existing program. If you do not have one, follow Set up a program first; it takes about a minute.

To complete all three steps yourself you need to be an organisation administrator or a super admin. With a site director account you can do steps 1 and 2 and will need someone else for step 3, which is what the control is for.

Step 1, write the charter

1. Open Programs, choose your program, and select the Charter tab.
2. Click New Charter.
3. Fill in the two required fields:
   • Title, for example, Summer STEM Enrichment Charter.
   • Mission Statement, the program's core purpose, a short paragraph.
4. Vision Statement and Scope Description are optional. Fill them in; they are shown on the card and there is no way to add them later.
5. Click Create Draft.

Checkpoint

A card appears with your title, a grey Draft badge, and the line "Version 1". The Total Charters and Drafts counters both go up by one.

Write it properly the first time, a charter cannot be edited

Correcting a charter is built and reachable from no screen. Once created, a charter's title, mission, vision and scope are fixed. There is no edit button and no delete.

If you get it wrong, create a second charter. The list orders by version, which is always 1, so both will sit there, and there is no way to mark the first superseded.

Step 2, submit it for approval

On the charter's card, click Submit for Approval.

Checkpoint

The badge changes from grey Draft to yellow Pending Approval. The Drafts counter goes down by one and Pending goes up by one.

What happened on PTRS's side: the charter was checked to be a draft or a previously rejected charter, moved to pending, and an audit entry was written. If it had been in any other stage, the move would have been refused, naming the stage; the guard is real.

Only a draft shows the button, though PTRS would accept a resubmit of a rejected charter too

A rejected charter can technically be resubmitted, and the Submit for Approval button only ever shows on a draft, so in the product a rejected charter cannot actually be resubmitted, and because it also cannot be edited, it is finished.

Bear that in mind at step 3 before rejecting anything you would want revised.

Step 3, approve it

You need an organisation administrator or super admin account for this step. If you have been following along as a site director, the Review button is not on your screen.

1. On the charter's card, click Review.
2. Type a comment if you want one; it is optional and it is saved.
3. Click Approve.

Checkpoint

The badge turns green Approved. An Approval History section appears on the card with one row: an Approved badge, the reviewer's email address, the review time, and your comment if you left one. The Approved counter goes up by one.

The card's subtitle now also reads "Version 1, Approved" with the time.

What PTRS actually recorded

This is worth knowing, because it is the only place in the Programs module where the answer is substantial.

Written	Where	Value
The charter's stage	the charter record	Approved
Who approved it	the charter record	the reviewer's email address
When it was approved	the charter record	the exact time of the review
A new approval history entry	its own table	reviewer name and identity, stage, comments, time
An audit entry	the tamper-evident log	"Charter approved by …"

Who approved a charter and when are written here, and nowhere else, in the Programs module. Rejecting instead of approving sets the stage to Rejected, writes the history row, and deliberately leaves both of those blank.

What this did not do

A guided first run should end with you knowing the boundaries of what you just learned.

Four things approval does not set in motion

• Nobody is notified. No email, no message inside PTRS, no alert. PTRS has never sent a notification of any kind, anywhere in the product. The approver finds out because they did it; the author finds out by looking.
• The charter has no dates. Its effective date and expiry date can only be set by the action that corrects a charter, which nothing calls. An approved charter is in force from no date until no date.
• It will never expire. Nothing anywhere sets a charter to expired or superseded, and nothing compares its expiry date with today. An approved charter stays approved forever.
• Nothing else changes. Approving a charter does not affect the program's own stage, its budget, its compliance requirements or anything else. It is a self-contained record.

Two things to know about who can approve

The separation of duties is by role, not by person

Approving a charter admits organisation administrators, regional directors and super admins, and excludes site directors. So the person running a site cannot approve their own site's charter, a real and deliberate control.

It stops there. Approving does not compare the reviewer with the author, and the charter does not record who wrote it. An organisation administrator can create a charter, submit it and approve it, and the approval history will show their own email as the reviewer.

CACFP's claim approval does perform that person-level check. Charter approval does not.

A regional director cannot do this at all

Approving a charter admits regional directors on paper. The Charter tab lives inside a program, and every tab there first loads the program's own detail before rendering. That check excludes the role, so the layout shows a failure message and the tab is never drawn.

A regional director therefore holds the charter-approval setting and has no screen on which to exercise it. Full derivation on Program funding & charter approval.

Where to go next

• Work the charter screen, the same screen as a reference, including everything on it that is fixed.
• What Programs can and cannot account for, the Budget tab next door, and why its figures do not connect to anything.
• Program funding & charter approval, the action behind step 3 and the five funding actions beside it.