Alludo supports rostering using a limited version of the One Roster 1.2 standard. Specifically, Alludo supports adding users, organizations, and roles using CSV files uploaded to an SFTP site. Once uploaded, these files are deployed to Alludo about once an hour. There are three steps to get started
- Contact support
- Receive your SFTP credentials
- Build your files
The first step to use automated rostering is to contact support with a request to get started uploading your roster into Alludo. Be sure to provide a technical point of contact in this request. Once we receive your request we will set up an SFTP username and password for you to use.
Receive Your SFTP Credentials
After your request is approved we will create an SFTP username and password and send this credentials to your technical point of contact you specified in the first step.
Build Your Files
Alludo supports rostering of organizations (orgs.csv), users (users.csv), and roles (roles.csv). As defined in the standard, the names of your rostering files are important. Incorrectly named files will be ignored.
- sourcedId - this is the unique identifier of the organization within your district. The One Roster standard defines this as UUID (a globally unique identifier). While a "best practice" it is not necessary to use a UUID for Alludo.
- name - the name of the organization. E.g., the name of a school site
- type - the type of the organization. Allowable values include school, local (Alludo group), department, district, state, and national. In general, you will use either "school" (school site) or "local" (group)
- parentSourcedId (optional) - organizations can "belong to" other organizations. Reference the sourcedId of the parent organization if you wish to nest organizations. For example, a Student Services might roll up to Educational Services for a district. Alludo supports one level of nesting groups (local).
- sourcedId - the unique identifier of the user within your district. Many districts use an employee identifier for adult learners. The One Roster standard defines this as UUID (a globally unique identifier). While a "best practice" it is not necessary to use a UUID for Alludo.
- enabledUser (Yes/No) - generally this is set to Yes but you may wish to use rostering to manage users access to Alludo. Setting enabledUser to "No" will remove that users access to Alludo.
- givenName - the first name of the user
- familyName - the last name of the user
- email - the users email address. Each user must have a unique email address.
- primaryOrgSourcedId (optional) - the school site of the user as defined in your organizations file.
- sourcedId - the unique identifier used to define each role definition. This is used for troubleshooting rostering uploads.
- userSourcedId - the unique identifier of the user
- roleType (primary/secondary) - a user can have one primary roletype within a given organization and multiple secondary roletypes with organizations. For example, you can define a teacher's relationship with their school site as primary and their relationship with their department - e.g., English department - as secondary
- role (administrator, aide, guardian, parent, proctor, relative, student, teacher) - the role a person has within an organization. In general, this will be defined as "teacher" for teachers, "administrator" for staff, and "student" for students.
- orgSourcedId - the unique identifier of the organization the person has a role with
The name, definition, and structure of your rostering files is important. To help you get started, we have defined each file described above for you to use: