CORE Minutes 8-22-06

· CORE Application Team

Discussion Items and Summary

Discussion Item/Summary

Approve minutes of August 15, 2006 Meeting

Communication Management (CM) Code Naming Convention: (DOC screen)

Kelley and Brenda explained the use and general protocol used for identifying/tracking documents and correspondence. CM is used to track all contact with students/individuals by phone, mail, personal visits, etc.; as well as automatically triggering reminders and responses. Every communication initiated needs to be “named”. CORE decides the naming convention, but the separate depts. develop part of the name to identify their own items.

The code name may have eight characters, alpha and/or numeric. Generally, the first two spaces are the Office Code. The following have already received final approval: AD=Admissions, FA= Financial Aid and RR=Records and Registration. As other offices begin to use CM, codes will have to be established through CORE. The third character denotes the type of communication, Datatel suggests C=communication/correspondence (incoming – telephone, email, etc.) and D=document (outgoing – email, letter requesting more info, etc.) The remaining four or five spaces can be used for identification by each “user” dept.

To avoid confusion, Datatel suggests not using the letter “X” or repeating letters that are in the first four code spaces for dept. IDs. “X” triggers an action or response within CM. Brenda noted that a specific communication “track” is assigned by various codes and triggers.

Admissions needs to develop training manuals before their next training session on Sept. 22, so CORE must decide protocol soon. (Note: Admissions goes “Live” Oct. 1) The fact that CORE must continually approve any new codes should be included in the manual. Brenda and Peggy will research CM use and appropriate naming for the next meeting, since Admissions and Financial Aid are main users of CM functionality. Brenda will discuss this further with their trainer during consulting on Friday.

PERSONAL.STATUSES: (BIO) Kelley received an email from Pat that this item must be decided to complete conversion mapping. This is the last of 12 required elements CORE must decide for this type of data; CORE has previously approved nine (9) and two (2) are for the city and state (electronically filled). The status codes currently in Test are: A=Active, I=Inactive, D=Deceased and M=Merged. These items were discussed, and Kelley noted that instead of “A” for active, the field can be left blank (to speed data entry). “Inactive”, per Pat, has been defined as last enrollment prior to Winter, 2000. It is assumed that “Merged” is used to eliminate/identify duplicate records.

There was further discussion and testing of these codes. On the BIO screen, if a “Deceased Date” is entered, a personal status code of “D” is automatically loaded. Current bad/“Unknown” addresses and 99999 zip codes were discussed, as well as their transfer to Colleague. (Can/should the address field be left blank? Will Colleague accept a zip code of “99999”?)

Kelley will research and review this element further with Pat; however, the “Deceased” and “Inactive” codes are needed ASAP (see Decisions Made #2).

ADREL.STATUSES: This is another area that may be used in data conversion. The codes entered in Test are: C=Current, F=Former, L=Last known, P=Pending. These were discussed and reviewed in Test relative to appropriate use and updating. Jean suggested a “bad/unknown” address could be coded as “former”. There is a “Bad Address” selection under “Mail Codes” (MAIL.RULES), which CORE hasn’t approved yet.

This element may also be used in converting data, so Kelley will include this in her review with Pat. Protocol and Valcodes should be reviewed in ADREL.TYPES (“Types” ADR), ADREL.STATUSES (“Status” ADR), MAIL.RULES (“Mail Codes” NAE) and ADDRESS.

CHANGE.SOURCE (“Source” NAE, ADR) to determine the most effective functionality.

ORGANIZATION DATA: work, discussion, and decisions

Kathy noted she hasn’t received any responses from the other community colleges she contacted; except for a couple that said they will try to find the person who can answer the questions.

Kelley talked to Pat and Joan about contacts and roles, especially the “Vice President” problem. They haven’t had a chance to get together and determine a reason or suggested plan to move forward. Jean noted that institutions (colleges) may be populated via electronic transfer (if database is purchased). Kathy wondered if this could create duplicates, since AP may already have entered some educational institutions in “live”.

To facilitate deciding the point of original data entry, Kelley and Kathy will meet with Rosemary and Beda, since most organizations are likely to be vendors. Questions were raised regarding what organizations Tom O’Brien and Sandy Schiller may work with through the BIT. Kathy will meet with them to discuss their needs and data entry processes.

Action Description

Planned Completion

Communication Management Code Naming Convention

Research use and appropriate “naming” for the next meeting, since Admissions and Financial Aid are main users of this application. Brenda will also discuss this further during consulting on Friday.

Conversion Mapping – Code Decisions

Research and review the possibilities and most effective use of the following codes for Legacy address data conversion: ADREL.TYPES, ADREL.STATUSES, MAIL.RULES, and ADDRESS.

>Discuss the point of original data entry with Rosemary and Beda; most organizations are generally vendors.

>Determine needs/uses of Lakeshore BIT

Approve minutes of August 15, 2006 Meeting

Recommend the following codes:

Prior Meetings - Open Items

Item Description

Planned Completion

Directory Information

Bad Phone Number Tracking

PENDING (Brenda questioned)

Revise Protocol for:

-Adding/Changing Data

-Deceased Individuals

Kelley will research and revise recommendations.

Library needs re: Personal data changes procedure

Contact Carol Briggs-Erickson – currently receives a list of changes from Records.

ADDRESS.TYPE Usage Protection by Module

Perry explained the address hierarchy process and will check on usage control.

Meet to review and discuss CE Access database functionality

Meet with appropriate staff members (i.e. Diana Osborn, Rosemary Zink, Cindy, Kelley, Patti, OIT)

Organization Data:

-Decide “Gatekeeper”

-Develop Protocol for Adding and Changing Data

>Check samples for Organization entry and maintenance protocol standards

> Research automatic Vice President role and other “role/special processing” issues with Perry, OIT, etc.

>Benchmarking (especially “Role”, “Contact” and “Employee” field usage)

>Practice and review organization data

> Reconsider EMPLOYMT.TYPES Valcodes: School Principal, Corporate Contact, Director, Employee, Officer, President, Sales Representative, Counselor, HR Director, Matching Gift Contact, Board Member. Try to reduce, simplify and condense options.

NEW Open Items

Item Description

Planned Completion

Communication Management Code Naming Convention

Research appropriate “naming” standards for use by various depts.

Conversion Mapping – Code Decisions

Research the possibilities and determine the most effective method for converting address data from Legacy

>Discuss the point of original data entry with Rosemary and Beda; most organizations are generally vendors.

>Determine needs/uses of Lakeshore BIT

NO MEETING Tuesday, August 29 (first week of Fall classes)

Next Meeting, Tuesday, September 5

Invited Participants

Student Life/Community Outreach

Records/Registration

[i] √: attended meeting; N: not present; S: sent representative; R: representative; G: guest

Core

CORE MINUTES

Meeting Logistics **REVISED 9/5/06

Core

document.write( 'Core' );

CORE MINUTES

Meeting Logistics **REVISED 9/5/06