FeePay Administrator Roles
FeePay is available to accept a wide variety of payments across an educational institution's business practices including Meals, Fees and Activities. Functional Roles have been designed in FeePay Admin for each area that works with these different sources of payment. The information below details the differences between these Roles. Please note: The FeePay Support team is unable to change security roles for FeePay Admin users. The school district is responsible for establishing security access rights/permissions.
Along with the parameters for each role, FeePay supports two security models which need to be verified before any Roles are set up. The two security models are Integrated and Standalone. If your district is currently using the TIES Online Access System (TOAS) to manage security, the Integrated security model is available. If you are unfamiliar with the TOAS security platform, your district will be using the Standalone security module. For a full overview on getting started with TOAS security, please see TOAS / FeePay Security Setup here.
This role controls access to the Admin Users page within the FeePay Admin. A user that manages district staff accounts in the FeePay Admin should be the only users with this role.
Users are granted access to all areas of the Administration site including Meal accounts, Fees and Activities. In addition, Administrators are able to manage all Settings including Resources, Forms, Activity Categories, Account Codes, Locations, Schools, etc.
Within TOAS, you will be able to set up a user on AD230 as a "Admin Power Users" security group/role. This role includes the ability to selectively update Student Physical Date and remove a Block Check.
Users with the Administrator role are not able to view/manage the economic indicator field for student accounts as there is a separate role for that.
Economic Indicator Administrator*
Users are granted access to view/manage the economic indicator field for all student accounts. This is to ensure absolute privacy of this sensitive information. All requests for access to this role must be submitted to your school district Food Service/Child Nutrition department directly.
Users are granted access to the primary areas needed for Fees and Activities. This includes the full Fees/Activities reporting suite and the majority of functions having to do with adding and editing Fees and Activities. Users are denied access to all system areas dealing with Meal accounts.
Note: To ensure consistent and accurate information when Activities are being set up, in Settings, a Fee Manager will only see the Transaction Lookup option. The Fee Manager can not add/edit Forms, Account Codes, Activity Categories or upload Activities and Fees to an entire student group. An Administrator would need to set up any Forms, Activity Categories and/or Account Codes in advance of any activities being created (Note: a Forms Manager can also create or edit any Forms). Once the Forms, Activity Categories and Account Codes are set up, the Fee Manager will be able to access them from the required drop-down lists during the Activity set up.
Within TOAS, you will be able to set up a user on AD230 as a "Admin Fee Users" security group/role. This role includes the ability to selectively update Student Physical Date as well. This role is unable to view student Economic Indicator information. Fee Managers need schools assigned (even if they get to access all possible schools). A Fee Manager user cannot have both Administrator and Fee Manager roles.
Food Service Manager
Users are granted access to all areas of the Administration site dealing with student meal accounts. This includes the full Meals reporting suite and all functions having to do with support of parents using FeePay. Users are denied access to all system areas dealing with activities and fees. Within TOAS, you will be able to set up a user on AD230 as a "Admin Meal Users" security group/role.
Users are granted access to Forms in the Settings options. If you wish to request access to this role, please contact the FeePay Administrator user(s) within your school district.
This role was created primarily for school Admin staff to be able to run reports and view information. ReadOnly users cannot have any other roles assigned to them. The following list defines, per tab, what they are able to do:
- User Search and Account Search: Has the ability to search students and users, but within those screens, all functions (such as add to cart) are disabled
- Activities: Has the ability to filter and run reports, view Roster, view Activity Form Responses
- Fees: Has the ability to filter and run reports
- Reports: In Fees & Activities Reports: Has the ability to view activity reports with three output types (html/PDF/XLS) and in Orientation Agreements: Has the ability to view list of documents acknowledged/agreed to by Orientation
This role is granted in addition to one of the other roles such as Administrator or Fee Manager. Users granted the Refund Administrator role will gain the ability to issue manual refunds within FeePay Admin. Using the transaction look-up tool, a user can view the details of a specific transaction to see the refund option. The Refund option is only active after a transaction has reached a completed status (i.e. an ACH debit is fully settled). Partial payments and Meal payments are not eligible to be refunded in this manner at this time.
Users with the Refund Administrator role receive voided payment notifications.
This role is granted in addition to one of the other roles such as Administrator or Fee Manager. Recurring Payments are similar to AutoPay payments. Recurring Payments differ from AutoPay in the way the payments are triggered. Unlike AutoPay's balance based trigger, Recurring Payments use a time based trigger. Recurring Payments are payments that have been set up on a schedule.
This role is a solo role given to users meaning users with the Roster View role are not allowed to have any other role. Roster View users are typically district staff that should have the ability to view activity rosters with corresponding form responses in real-time.
This role is granted in addition to one of the other roles such as Administrator or Fee Manager. The Simulate Permissions role provides the ability for Admin users to interact with the Meals, Fees, and Activities as a parent. This is ability is helpful in answering parent questions.
School Level Security
To establish school level security, please follow the steps for your security model below.
- An active user must exist in TOAS on OS110. Note: this user must have a valid e-mail login ID to proceed
- Within an hour, the user’s account will be available within FeePay. A District Administrator may create further school-level restrictions for Fee Administrators at this point.
- Upon login, the user will be able to perform any function that is available in the Fees/Activities module, but only for their assigned school(s)
- In FeePay Admin, select Settings then System then Users
- Select Add User
- Fill in the First Name, Last Name, Email (username), Password and Confirm Password fields
- Choose a role(s) for the new user
- Choose which schools you wish to restrict this user to from the drop-down list. If no schools are checked the user will have access to all schools. Only check schools when the user is to have limited access.
- Select Save
*Note: Permission specific role. These roles have one purpose and do not grant permission to multiple functions. For example, a user with one of these rules is able to see a page or a field that is otherwise hidden from all other users (including the general Administrator role users).
**Note: Fee Managers need schools assigned (even if they get to access all possible schools). The views for this role look to those assigned schools to complete a join process to the schools that are assigned in an activity. When an activity is applicable to user roles, the schools available need to be spelled out in the activity setup screen to ensure the join process can happen. It is essentially an exception the "no schools means all schools" rule in activity set ups.