Configuration Data

At the beginning of the installation process, Stellic works with institutions to complete a configuration sheet that includes the core data and setup process to create your unique instance of the Stellic platform. We will work with you to answer configuration questions that help us ensure that your instance matches your particular institutional context. For example: Do you refer to course units as credits, units, or some other term? Is the GPA value in your SIS truncated or rounded, and to how many decimal places?

The configuration sheet is completed primarily by the functional users at your institution, since they likely have the most awareness of the “rules” for how your SIS operates. However, the most effective way to complete the configuration process is to develop a strong collaboration between functional and technical users. Your Stellic implementation team will also assist you through the process to answer questions and discuss particular use cases or even demonstrate particular functions in the platform that might help you make wise decisions about configuration.

Like your own SIS, Stellic requires some core data elements in order to operate effectively. For example, we need to know the names of your terms, their order, and if they are used by all students or only by certain programs.

Yes, Stellic will continue to reference the configuration sheet for your institution after we complete the initial installation and configuration of your instance. In fact, we will intentionally review the values of these tables after we load your data initially. We will continue to refer to the configuration sheet during our testing of student data to ensure that the platform makes sense for end users and to make any needed adjustments. The configuration sheet will also be a resource as we continue to work with you into the future to help you launch new programs, add new data elements, and improve your use of the platform.

The following are some of the primary tabs included in the configuration sheet, an explanation for their use, and explanations for each of the fields included to assist with the selection of appropriate values for each.

Once the Main tab is defined, the next set of data is the Term Types that will be used in your SIS and in Stellic. Institutions often have historic terms in addition to those used today. A primary decision must be made regarding what terms will be used in the Stellic platform (which implies that not all need to be included).

So, how do you decide what terms should be used in Stellic? It is helpful to first consider what terms (semesters, quarters, blocks, etc.) students will use to plan for their classes. After all, the core of Stellic is the planning functionality. You may even have some terms that are used by groups of students at your institution and some that are only used by others (what Stellic calls Contextualized Terms). That all works but they must all be defined here

The display name for the term in the Stellic platform. This Name value will be used in various feeds (schedule, student, etc.) to indicate the term in which a course is offered, a student began a program, etc. This Name value must match the values in those feeds (Stellic doesn’t use term codes that might be used by some SISs so this may need to be “translated” in your feeds to match the display value. These Name values will be seen in dropdowns and other locations in the platform so they should be recognizable by platform users (and should probably match other term values displayed in other institutional systems).

This is not intended to be an actual date including a year but a month and day combination for a default start for this term. For example, if your Spring term always starts around January 5, you can use that date. This value will not appear in the Stellic platform but Stellic uses this value as your term start date in the event it isn’t supplied in our calendar feed yet (so the platform does not lose functionality until an actual start date for the term can be supplied and loaded).

As with the Start value, this should be the default value for the end of the term type (e.g., Summer term typically ends around August 15).

Stellic does not require a term feed in which we receive your term codes from the SIS to create a term record. We simply apply records to the terms that are sent in your feeds to Stellic. However, there are some advanced functions that would benefit from using the actual term codes from your SIS. So, this is an optional value that Stellic can use to map the final characters of your term codes to the specified term (e.g., Fall term always ends in “10”). One of these advanced functions is registration as SIS APIs often require a term code to function.

This is the order of the term within the institution’s academic year. This number should not overlap with any other term values. For example, if “Fall” is your first term of the academic year, you would use ‘1’ for this value and then list the rest in sequential order.

The order of the term within the calendar year. This number should not overlap with any other term values. For example, if you have a “Winter” term that starts in January, you would use ‘1’ for this value and then list the rest in sequential order.

Stellic will present a specific set of terms to students for the planning process and we use this value to determine if it is a term that should be a default term in the student’s planner. This is a Yes/No value where Yes would indicate that the term is present. Any No values would be optional and could be added manually in the planner by the student or advisor.

Sub-terms are the manner in which Stellic supports sessions within terms for scheduling. These become filters in the schedule search process for students and advisors. Stellic doesn’t need to know the SIS sub-term codes but only the display names. These names will also be passed in the schedule_basic feed. The only thing that is needed is the term to which the sub-term/session applies (so we can connect them together as appropriate) and their order (so we display them chronologically as may be appropriate.

You can certainly use consistent session names across terms, even if they have different SIS codes associated with them. Again, only the display names matter within the Stellic platform. There are no section-based enrollment limits by sub-term; only at the term level. Also, time conflicts are still enforced based on the class dates and times (so take care to clearly identify all class meeting patterns in the schedule_timing feed if concerned about overlaps; Stellic will still warn students about conflicts, just as would be done in a standard term operation without the use of sub-terms).

This value is the sub-term/session name that will display within the Stellic platform. This value will be included in filters within the term when searching for sections as well as display in the student’s planner. All sections associated with each sub-term will be displayed under the sub-term name and will be displayed according to the order of the selected sub-terms.

This is simply a validated link to the term name from the Term Types tab. Each sub-term name must be listed for each applicable term but the sub-term display name can be listed multiple times (if the same sub-term name is associated with multiple terms).

Each sub-term must be ordered for each term to determine how it will be presented in the student’s planner. Most institutions list the order chronologically so class sections that start sooner will be listed first.

Superadmin users do not have any special permissions within the Stellic platform except to be able to assign permissions to other administrative users. Superadmins will see the Staff tab and be able to activate/inactivate users (if not done automatically through a feed), create groups for permissions (and studentsets), and have access to manage permissions for users.

Stellic recommends at least two superadmins from each institution be assigned (more is also acceptable). These superadmins will have responsibility for permission assignments and they typically include at least one staff member from the registrar's office and one from IT (and sometimes from advising, depending on the institution's academic structure).

The core elements that is connected to a user’s account and is often used to join with other admin values in feeds (should mirror the ‘username’ value in the user feed sent to Stellic). This is typically the attribute sent via the SSO response so needs to match the values in your institutional systems. Also, this is a case-sensitive value for Stellic so you may need to review your SSO authentication response to ensure the case of this value matches what is being passed by SSO (often the cases differ between what you may have in your SIS and your directory service so you may need to “transform” the case of this data to match).

The institutional ID number for the student, typically numeric (but can be alphanumeric). This is often the unique identifier in your SIS or other user management system. Like the values in the user feed, this will be used to create a core user record and the User ID value may be used to link other feeds with this user (advisors, etc.) so this should match whatever value is sent in the ‘id’ column of the user feed.

The user’s first name. This value will be displayed in the Staff record and throughout the platform if connected to students and courses.

The user’s last name. This value will be displayed in the Staff record and throughout the platform if connected to students and courses.

The email address of the user (typically, an institutional email that can be used to reach the user). This will be displayed in the user’s Staff record.

Limited superadmin users are able to assign permissions to other users permissions but only in a limited way (compared to a regular superadmin user). A limited superadmin cannot grant permissions for any function that is greater than the permissions already assigned to them.

Limited superadmins can also be granted ""Moderator"" status for a defined group within the platform. This allows the moderator to activate/inactivate other users within that group while not impacting the user's ability to access other functions in other populations that may exist (which would be managed by other superadmins or limited superadmin moderators of other groups). The group (defined within the platform permission functionality) contains the definitions for the population (which students or programs are included).