Below is a list of commonly used words and designations used by Regpack Product Specialists, Regpack Project Managers and our Regpack Support team.
The “front end” of the system is what your registrants will see. This is the side of the system that you will use to test your user experience and ensure that your registrants will see what you want them to, that your conditional logic is working properly, and that everything is running smoothly!
The “back end” of the system is what you and your admins will see. This is where the managing, creating, and editing of your Regpack system will take place. In the back end, you’ll see your Regpack Tools:
Users, Payments, Settings, and Help. From here, you can adjust the products/discounts, report and email templates, forms/fields, scheduler units, auto billing options, admin levels and permissions, your bill, and your project settings. Everything is built out in the back end; your registrants will not see this side of Regpack.
In Regpack, we organize registration processes into projects (or systems). Each project is a database full of your registration forms, emails, reports, financial details, and user information for one specific registration purpose. Each time you copy your project or create a new one, you are beginning a new database for a separate registration purpose. We sometimes think of it like a filing cabinet full of manila folders. You have one folder (project) for one process and another folder (project) for a different purpose. Technically, you can manage multiple processes within one project (by using conditional logic), but we usually recommend using multiple projects so that you’re more organized and ready to pull reports when needed.
Sub-unit (child)/Head unit (parent)
There are two organizational structures in Regpack: Individual registration (someone signing themselves up) and Group registration (someone signing up multiple people/on their behalf). Group registration has a head-unit and potentially multiple sub-units. The head-unit is doing the registering (they’re your main contact) and the sub-units are the ones being registered (actually attending your program).
The sub-unit or child within your Regpack group system is typically where your participants will be listed. Think of the parent as the umbrella and the children as the people under the umbrella. You may have adults registered as sub-units, but you need something to link them together since they’re signing up as a group — this is your head unit/parent!
In Regpack, there are two places that users can register: through a link that directs them to a hosted page (like the front end you used to test) or directly on your website where the registration process is embedded. The way you put and keep registration on your website is by using our Iframe. The iframe is one line of HTML code that you copy from your project and paste on your website; it’s basically a window into your project that lives on your webpage. You can find your iframe code by going to “Settings” > “Project Settings” > “Embedding” > and scrolling to the correct section.
Embed/Integrate (registration on website)
Yes, your registration process can be on your website so that your applicants never get directed away — instead, they stay right where you want them, looking at your website URL. With us, it’s one line of HTML code you copy from our side and paste on your website. The resulting iframe is transparent and allows your applicants to walk through your registration process.
Token (for email)
Since the questions you ask your applicants are up to you, the information you gather is under your control. It only makes sense that the resulting emails should also be under your influence. With Regpack, you make the blueprint; then, the predetermined “tokens” — corresponding answers you’ve gathered to the questions you’ve already asked — will automatically fill in. The mail-merge ability is what personalizes the emails and is one of the ways we save you some time.
An applicant is someone who goes through your registration/application process and gives you information. You as the admin have the ability to decide whether they should stay active or if they should become inactive.
Once someone becomes a user in your project, they’re active. But, like your email inbox, you can archive applicants (like when they cancel or finish your program). If they’re no longer essential to your business (whether that’s for reporting, marketing, or communication reasons), then you can make them disappear from your user list (note: you’re not deleting them — you’re just putting them in an archived folder).
An admin is someone who has login access to your user data. There are different levels of admins that determine who can view the collected applicant information, manage said information, send emails, download reports, and make changes.
You can restrict what an admin can do or who an admin can see by putting limitations on them. Those limitations can be per project.
ACH / E-check
This payment option is currently only supported with US-based bank accounts. It is a type of electronic transaction (different from credit card). An electronic check records the same details as a physical check, but it processes electronically within 5-7 business days (saves you a trip to the bank).
In Regpack, “triggers,” or our conditional logic, usually take the appearance of a tiny lightning bolt. By applying a “trigger,” you create rules where certain actions will lead to the appearance/disappearance of key details.
Common triggers include setting additional fields (questions) to appear, ensuring specific discounts apply, setting specific product options to appear, setting certain emails to send, or adding certain forms as required. These rules can apply across several areas of your registration flow.