SFReg User Guide

Overview

SFReg is the registration step between a course booking and a certificate. Each attendee gets a private link, confirms who they are and gives their details without logging in. If they want NZQA Standards, SFReg also finds or creates their National Student Number (NSN).

• AttendeesUse the link, complete the form and receive the emails.Form pages
• Customer Service and Training AdministrationSend new links, work help cases, release holds and resend certificates.Staff tools
• TrainersCheck attendees in and record the result of the course.After the course
• Content editorsChange form and email wording without a deployment.Site content · Emails

The full journey

Read left to right. Each coloured band shows who does the work, and the headings point to the section with the detail.

Course booking

A booking comes from the website, or from Customer Service using Order Quick Create. Salesforce creates one Service per attendee. That record, ContactAssetRole__c, holds the registration from here on and starts at status NYA (Not Yet Attended).

Who sends the booking email

SFReg sends it, with the registration link, when all of these are true. Otherwise the older booking email path applies.

• The record is an active attendee, and not a placeholder seat.
• The course is public, not private.
• The course date hasn't passed. Online and youth courses are exempt from this.
• The booking has no Blended add-on set to TRUE.
• An active email rule exists for the product (see Dynamic emails).

If the attendee's NZQA Required add-on is TRUE, they get the NZQA version of the email. If a booking email fails to start, an hourly sweep picks it up and sends it.

Registration link

The link is the attendee's only key to the form, so there's no login and no account to create. It works once. Opening it starts a session of up to 4 hours, and refreshing the page can use up the link. If someone else opens it, they can use it too, so the booking email asks people to forward it to the actual attendee rather than click it themselves.

Links are created for booking emails, reminders and resends. Each new link switches off the one before it.

Form pages

A progress bar across the top shows four stages. The examples below use made-up data and the wording set in QA.

Show the Site Content keys

Page 1: Confirm Attendee

• Name change only: the booking is corrected in place, and any NSN result is reset so it's checked again.
• Different email address: SFReg asks "Is this a different person?". If they confirm, it's a seat swap (see section 7).
• Only one legal name: the attendee ticks "I have only one legal name" and types it once. SFReg saves it in the NSI's format, with ~ as the first name and the real name as the last name. It also recognises ~ in saved names, ticks the box and shows the real name (V0.99.50).
• After the course: name and email are locked to the person registered. If the form is also finished, the attendee is asked to contact us.

Page 2: Additional Details

• Asked of everyone: name, date of birth, phone number, address, ethnicity and gender. Employee ID is optional. A full address is required for NZQA.
• NZQA choice: shown only when the course offers it. It's a tick box, and opting out takes the attendee straight to page 4.
• Residential status: Australian citizen, overseas or "I am not sure", or a citizen or resident who ticks "There has been a change to my residency status", shows We'll need to speak with you and leads to a case (see section 6).
• NSN: entering it is the most accurate route. NZQA's Awhina assistant is linked for anyone unsure of their number.
• Previous names: used for the search only, not saved to the registration (V0.99.48).

Page 3: Validate Identity

Only needed when a new NSN has to be created, or an NZQA record must be confirmed. See section 5.

Page 4: Confirmed

The wording depends on the outcome: NSN verified, new NSN created, NSN still being confirmed, identity attempts used up with a case raised, NZQA declined, or already registered.

NSN and NZQA check

When an attendee chooses NZQA Standards, SFReg checks the National Student Index (NSI), NZQA's record of students, while the form waits. The two routes on page 2 use different searches but finish at the same decision.

Rules worth knowing

• Exact means exact on the record. Case, spaces and macrons are ignored. The first-name box matches the record's first given name alone or with its middle names, in order (V0.99.49). A middle name on the record doesn't stop a match, but a typed one must be on the record.
• Previous names are searched too. If the current name finds nobody, or one person who isn't an exact match, up to three more combinations run with the attendee's previous names (V0.99.48). If different people come back, the search stops.
• Stops are deliberate. If SFReg can't be sure it has the right person, it stops rather than risk putting a qualification on the wrong record.
• An unverified NSN is never shown. It stays on the server until the identity check passes.
• Too many checks in a short time show "You’ve made several checks in a short time", with a time to try again.

Identity check

NZQA requires a confirmed identity before an NSN can be registered. An identity verification service compares the attendee's name, date of birth and address with their document. Those details have to match the document exactly.

• Forms of ID: New Zealand driver licence (preferred, age 16 and over), passport or birth certificate.
• Most common cause of a mismatch: a name recorded differently, such as "Dave" instead of "David", or a missing middle name. "Edit these details" takes the attendee back to fix it.
• After a pass: a found record is used as it is. Otherwise SFReg creates a new NSN and page 4 shows it. If the new NSN can't be confirmed straight away, an hourly job keeps checking and raises a case after 24 hours. The confirmation email waits until the NSN is confirmed.
• If the NSI says the person already has an NSN when creating one, SFReg doesn't treat that as success. It raises a case.

On hold and help cases

When the form can't finish online, a Case goes to the Training queue with type Customer Request - Training and reason NZQA Query, linked to the Service. The attendee sees the case number and gets an email.

Getting a booking off hold

1. Work out the record with the attendee. Correct the name or date of birth if needed.
2. On the Service, use Act on Behalf. Send new registration email or Opt in to NZQA & send email releases the hold after you confirm. Open registration form keeps it.
3. Releasing clears the search stop and resets the look-up attempts to 0. The case stays open.
4. When the attendee finishes, the hold ends and SFReg closes that help case. If you released or reset a booking and it doesn't finish, close the case yourself.

Someone else attending

The email address decides who the booking belongs to. If it changes on page 1, and the attendee confirms "Yes, send a new link", a new Service is created for the new person and the old one goes to status Swapped.

• New attendee: gets a fresh link and fills in the form from the start.
• Previous attendee: is told the place has been given to someone else (EMAIL_SWAPPED_OUT).
• Person who booked: gets a notice, unless they're the person displaced (EMAIL_SWAP_BOOKER_NOTICE).

The swap runs in the background and is checked again on the server. The form shows progress, then "We've sent your new registration link". Swaps aren't available once the course is over.

After the course

Course day and result

• Classroom Portal: staff and trainers see the course roster with who has registered. "I'm in" moves an attendee to ATT, and they can correct details or mark DNA. Check-in emails anyone who hasn't finished their form.
• Result: the trainer records competency through the training portal, which moves the booking towards a certificate (C, then CR).

Finishing the form after the course

The attendee can still finish. Their name and email are locked, and NZQA can't be changed once they've registered for it. NZQA stays open until the close-off, eight weeks after the course's first day. At close-off, anyone still not ready has NZQA set to FALSE and gets a standard certificate with the closure email.

Certificates

One rule decides which certificate a booking gets, so the hold, the release, the closure and the issue step always agree.

What the attendee gets

An email with a PDF attached, named Cert_<First>_<Last>_<number>_<yyyyMMdd>.pdf. The PDF comes from the Dynamic Document engine: the NZQA or standard template set for the product. A copy stays on the Service as a File.

Safeguards

• Issued once: a booking already sent, in SFReg's records or the status history, goes back to CS and isn't issued again. A second copy is a staff resend of the stored file.
• One exception: a finished registration reopened for NZQA before close-off can receive the NZQA certificate after a standard one.
• Failed render or email: stays at CR and is tried again the next day.
• No email address, or opted out of email: the certificate is filed and the booking moves to CS. Staff resend it once fixed.
• Older bookings with no registration: get the "Please finish" email and then follow the normal path.

Which system issues the certificate

That depends on the org's integration mode.

Dynamic emails

Editors change most SFReg email wording in Salesforce without a deployment. Three things work together: a rule says whether a product sends an email and which template it uses, the template holds the layout, and a content record holds the words.

Which email goes when, and to whom

Subjects are as set in QA and can be changed in the manager. All emails come from training@stjohn.org.nz.

SFReg also sends an SMS two days before the course and with the final reminder. Failed sends are retried hourly. Other training emails, such as private and blended bookings, still come from the older path.

How the words are chosen

The rule, a Definition_Attribute__c row of record type Rule, is looked up on the product by name, for example EMAIL_POST_COURSE_CERT. The most specific level wins: Option, Variant, Offer, then Family. Rules currently sit on the First Aid Training family.

The words come from Dynamic_Email_Content__c, matched on Template_Key__c. A row for the product wins, otherwise the Default row (blank Definition) is used. QA and UAT currently hold 14 Default rows and no product overrides.

The parts of an email

Blocks 1 to 6 are optional, and an empty one doesn't show. Merge fields such as {!relatedTo.Asset__r.Name} fill in details like the course name. Sent By and Reply To are also stored on each row.

Changing an email

1. Open the Dynamic Email Template Manager tab in Salesforce. You need Edit access to email content.
2. Pick the email from the list. Its status shows whether a rule and content exist.
3. Edit the words on the left. Edit HTML (advanced) is under Settings. The subject line and footer are edited here too, and one footer can be saved to all templates.
4. Check the preview on the right, on Desktop and Phone. Choose a sample booking to see real merge data.
5. Select Save. The next email sent uses the new wording, with no deployment.

Site content

All form wording can be changed by updating Sites_Content__c records, with no deployment. The form ships with its own default wording, so a missing or switched-off row can never leave a blank page.

What's on a row

How keys are named

A key is section.name. The form treats a dot and an underscore the same, so p1.continue and p1_continue are the same key. Some rows use the underscore form, such as p2_nsi_ambiguous_title.

Changing the wording

1. Find the wording in the Site Content map, or use Show the Site Content keys in Form pages to see which key sits where.
2. Open the Sites Content tab in Salesforce and find the row. If there's no row, create one with the exact key, site SFRegRegistration and Is Active ticked.
3. Change Body__c. Keep any placeholder exactly as it is, such as {caseNumber}, {supportPhone}, {time}, {ref} or {n}.
4. Save, then open a fresh link in a private window. The browser caches content, so an open session may show the old words until a hard refresh.

See every screen with its keys

The Site Content map draws each form screen in order and shows the key beside every piece of text, with when it appears. It covers 286 keys, built from the V0.99.50 form code and rows read from QA and UAT on 02-Nov-26.

• Rows: QA has 172, 158 of them active. UAT has 166, and their wording matches QA. The other 6 QA rows show the built-in wording in UAT.
• No row yet: 114 keys show the wording built into the form. Add a row to change one.
• Not used: 9 active rows do nothing in this version, because the form no longer reads them.

Open the Site Content map

Staff tools

SFReg: Act on Behalf

This card is on the Service record, for authorised staff only. A Registration line shows the current state, and the latest change made outside the form.

Classroom Portal

An internal Lightning app showing course rosters. Staff and trainers check people in, correct their details and see who has finished registering. Correcting an email address starts a swap. Correcting a name or date of birth restarts the registration, and the attendee gets one email.

Where to look on a Service

• Emails: an Email Message and a Task are logged for each send.
• Certificate decision: the latest registration attempt holds the decision, reason and outcome.
• Certificate file: Files related list, named Cert_….
• Help: the Cases related to the Service.

Statuses

Status__c stores short API values, which reports and data loads must use. Screens show the readable names.

Registration state on Act on Behalf

Background jobs

These keep the journey moving without anyone acting. Any test environment can have a job paused.

Common questions

Glossary