Not Started Project Idea: Student Attributes

Detailed Information

Meeting with Jeff Jensen, Corina Larsen and Linda Reid, 8/29

Linda would like to investigate the use of (currently unused) Student Attributes for the tracking of Collaborative Programs. These are collaborative certificates and degrees between a number of UMS institutions. Linda, can you add to this?

Our discussion surrounded how to implement the use of Student Attributes in a way that gives structure and at the same time autonomy to registrars to use these attributes to the advantage of their institution as well as the benefit of the UMS. In order to accomplish this, the registrars would first agree on the overarching uses of attributes: current ideas are for tracking Collaborative Programs and Competency Based Education.  Next, Linda suggested a "place" where registrars can go to see which attribute values currently are available and make a determination if an existing attribute would work for them, or if they need to create a new attribute. This could be done with a query on the attribute table. Additionally, there could be a self-service web page which listed the Student Attributes uses and queries, as well as instructions to enter new attributes, assisting in giving registrars autonomy to use and create attributes.

Student Attributes, when being set up, have the option to be tied to an Academic Career or Academic Program. In our discussions, we recommend that it would be best to make it a requirement that the attribute is tied at the career or program level. Attribute types that are assigned to anything below the career or program must be added AND removed manually, but if the career or program of the student changes, the attribute is automatically removed. There was discussion around using queries to determine if, for example, a student's Academic Plan changes, the query identifies that it is now associated with the wrong attribute. These could be run on occasion, possibly by registrars or DARTS, and the data can then be cleaned.

The discussion then turned to Data Governance. We agreed that implementation of using Student Attributes would be a great test case for a policy/procedure process. Because Student Attributes are currently unused, and the tables are empty, this process, once finalized and tested, may prove to be a useful framework for other DG data input issues. It was suggested that a proposal for Student Attributes could fit well into Linda's current work group.

 Jeff mentioned that we could get this running relatively easily in a test environment where specific testing could be done in order to understand precisely how the Student Attributes work to inform the procedures as well as identify any pitfalls. Corina did some research surrounding Student Attributes, and there was not much information to be found on issues using them. 

Additionally, there would also need to be some research into implementation from a DBA perspective. It appears that there are things which need to be done that Linda does not have access to accomplish. Specifically, there is a page with a tab in PeopleSoft that allows migrating the Student Attribute from the admissions screen to the Student Enrollment screens for tracking through a students career.  That tab would need to be enabled, probably by the DBA group, and tested before moving to production.

Overall, we are all very positive about this being a successful project and we would like to determine next steps with Rachel Groenhout.

Oracle

• Tracking Student Attributes
• Setting up Student Attributes

What are Student Attributes?

• Based on academic career and academic program
• Can assign many attributes to one student
• Used for creating and grouping cohorts reporting
• Can create multiple attributes, each with multiple values using the Student Attribute Table
• Can be assigned at any time throughout the student's career
• System reports a primary student attribute as part of the Consolidate Academic Statistics process
• The system uses a primacy number to determine the primary student attribute value it uses when you extract data to report on cohorts. Lowest number takes precedence.
  

Although student groups enable you track attributes such as participation in clubs, sports, and student government, you might need an additional, more flexible structure that lets you track the attributes of your students based on their career and program. To meet this need, use the Student Attributes feature.

The Student Attributes feature enables you to assign all sorts of attributes to a student within an academic career or program and group together the students with similar student attributes. You can then track and report on the student attribute data. For instance, you can track students that begin their education at the same time as a single cohort by creating a student attribute for undergraduate incoming freshmen and attaching the attribute to the records of these students. You can then use the data for federal reporting and also for institutional research purposes to gain information about the type of students that you have in a particular cohort, such as a student's typical course load or how long it takes a student to complete his or her program and graduate.

You can create multiple attributes and multiple attribute values within a single attribute. Then when you assign these attributes to students, you can attach to their records multiple attributes and multiple values within each student attribute. With this flexibility, your students can belong to as many cohorts as necessary to meet your tracking and reporting needs. You can assign these attributes to students at any time, even during the recruiting and admissions processes because the attributes roll from PeopleSoft Recruiting and Admissions to Student Records as part of the student's academic career and academic program.

Use the Student Attribute Table component to define different student attributes and student attribute values. You can create broad student attributes for entire academic careers, then attach single student attribute values to each of those careers. For example, you can create a student attribute for undergraduate students called Student Cohort. You can then create different values for Student Cohort on the Student Attribute Value Table page (such as Fall 2005 Entry Class, Fall 2006 Entry Class, and Fall 2007 Entry Class). In addition, you can create smaller student attributes for individual academic programs. You can also define student attribute values for plans and subplans and group them under a specific academic program.

After you define all your student attributes and student attribute values, use the Student Attributes page to attach these attributes and attribute values to individual students and build reports on the data so you can track statistics such as how many students in a particular cohort graduated in three years, four years, and five years, and how heavy their course load was. The system also reports a primary student attribute as part of the Consolidate Academic Statistics process.

Student Attributes Examples

• Washington State Board for Community and Technical Colleges 
  • Used to identify specific workforce retraining reason

Student Attributes Issues, My Oracle Support

• Duplicate Values in Student Attributes Prompt Table in Student Program/Plan When Emplid has Program Actions on Same Eff Date (Doc ID 2408845.1)
  • Base Table Not Populated When Student Attributes are Updated in Multi Language Environment (Doc ID 1998180.1)

Other

• Understanding Student Academic Projects
• Understanding Common Attribute Framework
  • Common Attribute Framework enables you to define a common attribute and add the common attribute as a data field to a Campus Solutions page . A user can then enter a value on the page for the data field.
  • A common attribute is a data element and is associated with a record in the system. A common attribute has the following properties:

  • • Name

    • Type

    • Default value (for example, a common attribute field on the user interface can show a default value that a user can change)

    • Format (for example, suppose a user enters a value in a common attribute zip code field. In such a case, you may want the system to automatically append a hyphen between the fifth and sixth character when saving the value to the database)

    • Validation

  • The framework delivers the following attribute types:

  • • Date

    • Time

    • Yes/No

    • Number

    • Long text

    • Text (maximum number of characters is 50)

    • Short text (maximum number of characters is 20)

    • List of values

  • To implement a common attribute, you must perform the following steps.

1. • Use the Application Designer to:

   1. • Identify the record that needs to be extended with attributes. For example, to add attributes to the General Materials page, you will choose the GENL_MATERIALS record.

      • Create a child record with the same key fields as the identified record. Add the CAF subrecord SCC_CAF_SBR to this child record. The framework uses this child record to store attribute data.

      • On pages where the identified record is used, add the delivered subpage (SCC_CAF_LAUNCH_SBP or SCC_CAF_SBP depending on the desired user interface experience).

   • Use the Common Attribute page to:

   1. • Create attributes that you intend to associate with the identified record. For example, if you want to add Passport Number and Primary Institution fields to the General Materials page, create two attributes: Passport Number and Primary Institution.

      • Define the attribute type and format.

   • Use the Record Context page to associate the attributes to the record. Continuing with the above example, use this page to add the two attributes to the GENL_MATERIALS record so that the two fields appear on the General Materials page.

• HEUG Presentation on Common Attribute Framework (PeopleSoft CS 9.0)
• This presentation will be a case study of everything learned by the University of Michigan staff about the Common Attribute Framework.  Our journey into CAF started when we received complaints from campus about the short, abbreviated descriptions for our Academic Programs.  The Student Records team was asked to add a longer description field to the page.  Instead of modifying the PS_ACAD_PROG_TBL record, we decided to try out the Common Attribute Framework.  We found it to be quick and easy to implement, as well as simple to maintain.  Join us in this presentation to see how we made the decision to CAF-enable instead of modifying, along with some helpful tips for implementing CAF.
• The presentation will include the following information:

1. • Review of the use case for adding a longer description to the Academic Program table.

   • Walkthrough of the evaluation that was done to compare CAF to other, more traditional ways of making page modifications.

   • Overview of how to enable the CAF on a page

   • Security and migration considerations

   • Use of PS Query with a CAF field

   • Final thoughts on CAF

   • Review of the other delivered CAF-enabled pages

   • Q&A