Regpack Terminology

below is a list of commonly used words and designations used by regpack product specialists, regpack project managers and our regpack support team ach / e check this 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) this payment option is currently only supported with us based bank accounts admin 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 applicant/registrant/user 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 active/inactive applicants once someone becomes a user in your project, they’re active once applicants are no longer essential to your business (like when they cancel or finish your program), you can mark them inactive in the system when applicants are marked inactive, their information disappears from your active user list but you can still access their data if needed back end 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, auto billing options, admin levels and permissions, and your project settings everything is built out in the back end; your registrants will not see this side of regpack embed/integrate (registration on website) your registration process can be embedded on your website so that your applicants they stay right where you want them, looking at your website url we provide one line of html code you copy from our side and paste on your website the resulting iframe is allows your applicants to walk through your registration process front end 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 iframe in regpack, there are two places that users can register through a link that directs them to a hosted page/template (like the front end you used to test) or directly on your website where the registration process is embedded the iframe allows you to have the registration through regpack right on your website 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 permissions you can restrict what an admin can do or who an admin can see by putting limitations on them those limitations can be set per project system/project 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 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! token (for email) tokens correspond to the answers you've gathered from your users based on the questions you asked in your forms you can add tokens to the emails you send out in regpack to personalize them with each user's information the tokens will automatically fill in information for each individual based on how they've answered their forms trigger 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