Shared categories, or shared requirements, are requirements designed to be shared between multiple audits. For example, if you have 5 art majors that all share the same electives, you can create the list of electives once and then use that same elective category in all 5 major audits. You can centrally maintain the shared requirement and when you publish changes to it, those changes reflect on the 5 major art audits. This approach saves time both when building requirements and when editing the list of electives.
Shared requirements are not a standalone audit. They must be inserted into a program audit or General Requirement to be visible to students. They function as a section within a larger program audit.
Creating a Shared Requirement
You can create a shared requirement if you have the permissions. To learn more about permissions, see Audit Permissions.
To create a new shared requirement:
Navigate to the Programs tab.
Click Create New and select Shared Requirement.
Select a name and scope from the pop-up menu.
If you select any scope criteria for the requirement (such as specific programs or departments), it is only available for use in audits within those designated areas. For example, if you select "Art Department" as a scope, only programs linked to the Art Department in your institution’s data in Stellic are able to use that shared requirement within an audit.
Considerations:
Because students cannot see Shared Requirements within the list of programs in the Programs tab, there is limited risk in making Shared Requirements available to a broad scope. For smaller institutions, it is common to make all Shared Requirements available for the entire institution. For larger institutions, where a sizable catalog of Shared Requirements may be confusing for audit builders, segmenting to a narrower scope is recommended.
Naming conventions: Determine a standard naming convention that will allow you to easily differentiate between shared requirements and versions of requirements over time.
The name of the shared requirement will not be visible to students or other users within the program audit or General Requirement. When you link the published Shared Requirement to a program audit or General Requirement, you will choose a “friendly” name for display in the program audit or General Requirement.
Versions: There is not a concept of versioning with Shared Requirements in Stellic. If you need to have two different versions of a Shared Requirement, you will need two separate Shared Requirements. This means that adding version information into the name of the Shared Requirement is good practice.
You can also copy requirements from an existing shared requirement and edit as necessary.
Once the new shared requirement has been created, you can add categories and courses just like any other audit.
A shared requirement must be published before it can be available for use in program audits or General Requirements. Because students cannot see shared requirements in the Programs tab, there is no risk to publishing audits during the implementation phase.
After publishing, you and other users can add the shared requirement to audits as needed. Note that when searching for a shared requirement to add to an audit, only those with criteria that match the current audit will appear in search results. For example, if you’ve set the Shared Requirement to only be available to the Biology Department, but the Biology Minor does not live under the Biology Department in the SIS data flowing into Stellic, the Shared Requirement will not be available to the Biology Minor.
Editing a Shared Requirement
To edit an existing shared requirement:
Navigate to the Programs tab.
From the search bar, select the Shared Requirement filter to refine the search.
Click on the requirement to view audits currently using it.
Click Edit this Audit to make changes.
Important: Once you publish the shared requirement, any changes made to a shared requirement will be automatically populated into all linked audits that contain the shared requirement. Always test the requirement using 'try on a student' before publishing. You can view which audits are using the linked Shared Requirement by clicking on the "Audits" menu when viewing the Shared Requirement.
Linking/Unlinking Shared Requirements
Shared Requirements can be unlinked after they are added to an audit. If you unlink a shared requirement, it will no longer be "shared" - meaning changes to that shared requirement will not affect any unlinked audits.
This feature is commonly used when building audits that have similar but not identical requirements. You can add a Shared Requirement to an audit, unlink it, and then customize it for that specific program. This approach saves time during the initial building stage since you don't need to create the requirement from scratch, while still allowing program-specific modifications.
Important: Any changes made to a shared requirement will be automatically populated into all linked audits that contain the shared requirement. Always test the requirement using 'try on a student' before publishing. You can view which audits are using the linked Shared Requirement by clicking on the "Audits" menu when viewing the Shared Requirement.