Setting Up Translation Tables

Click here to view related articles.
25Live Fields vs SIS Data
Key LYNX Settings
Setting Up Translation Tables
Mapping Event Names, Categories, and Attributes
Best Practices for Optimizer Partitions and Preferences
Utilizing Meeting Patterns and Standard Schedules
At the Start of Each Term
Roll courses/exams over from previous term
Initialize reference data in LYNX
Using and Understanding Extract Sets
Tips for Import Extract Sets
Tips for Export Extract Sets
Create date exceptions
Test extract sets and import data into 25Live
Review errors and conflicts
Placing Classes Using Optimizer
Finalize bindings between sections
Review Best Practices for Optimizer Runs
Run the Optimizer to find placements
Tweak settings to improve your Optimizer results
Ongoing Throughout Term
Updates Throughout the Term
Ongoing Maintenance for LYNX
Finishing a Term
Final Exams
Tips For Final Exams in LYNX

Both 25Live and your student information system (SIS) contain the same kind of data. Each of them has some way of tracking classrooms, subject codes, campus names, and more.

Since these systems sometimes use different names for the same thing, LYNX must translate between them to keep everything straight. That's where translation tables come in. Each translation table is a set of rules that tell LYNX how it should convert from one system to the other.

Most of the time, LYNX's default translation rules will be sufficient and you won't need to touch them. This page will guide you through some of the factors that may influence your decision to customize the defaults. For in-depth instructions on creating and modifying translation rules (as well as an explanation of "Else" rules) see our article on Data Translations in LYNX.

  • Don't set up your translation rules until you're satisfied with your other configuration settings (link), as these can affect which translations LYNX uses.
  • Make sure you have created the translation targets (such as event types, event categories, organization names, etc) in 25Live before attempting to set up rules.
  • If the names for things in 25Live don't exactly match the names or codes in the SIS, then you will need to set up individual rules to map each item instead of relying on an Else rule.
  • It's possible to translate multiple things in your SIS into the same thing in 25Live. For example, you can map both "LEC" and "LEC/LAB" into "Lecture" or map all term codes ending with "FA" into "Fall Semester".
  • After you set up your rules, verify that they behave as expected by previewing with the View Translated Results button.
  • When you preview results, you may see an alarming number of fields marked as "No". LYNX translates everything in your SIS, even old or expired codes that you don't intend to use with Series25. You can group all the relevant results together by sorting the table by the "Valid" column.

Status Codes to the Event State (required at implementation)

Events in 25Live have multiple possible states, including Tentative, Confirmed, and Cancelled. LYNX determines which event state to use based on a section's status code in the SIS. This is a highly important field that often includes codes unique to your institution, so you should not rely on LYNX's defaults. Visit this translation table to ensure your events are imported correctly.

We recommend that you choose one of the following models for your translation rules:

  • Choose a specific status code (or codes) to mark as Confirmed, and set the Else rule to Cancelled
  • Choose a specific status code (or codes) to mark as Cancelled, and set the Else rule to Confirmed

Note: the difference between Tentative and Confirmed is a matter of preference, as both states are equally able to assign locations. Most schools choose to make all of their imported sections Tentative or all of them Confirmed, while some distinguish between the two based on the status code in the SIS.

Additional Items That Can be Addressed at Implementation

Event Types

This translation is hidden if you have chosen to give all your imported events the same event type, such as "Section". Otherwise, you'll have the option to match the 25Live event type to one of the following fields depending on your SIS:

  • Campus Code
  • Institution Code
  • Region Code
  • Section Type Code

You'll likely want to set the Else rule to None and create explicit rules for each event type. For example, set up a rule that maps the section type "LEC" in your SIS to the event type "Lecture" in 25Live.

Note that it is not possible to combine two types of translation rules. For example, you cannot use both the campus code and the section type to produce an event type like "Lecture - Main Campus". If you wish to add both kinds of data to your event, consider using event category translations (below) or adding custom attributes (link).

Event Categories

Image: Translation rules in LYNX

Depending on your SIS brand, your configurations can enable several different translations to add categories to events in 25Live based on SIS data:

  • Academic Career Code
  • Campus Code
  • Institution Code
  • Subterm Code
  • Term Code

Adding SIS data as event categories can be useful for event routing purposes (link) but it involves more administrative upkeep. You may want to consider adding data as custom attributes instead. (link)


An event's organization in 25Live corresponds to either its subject code or department code in your SIS. This code also appears in the event name.

Since they are so plentiful, it's best to avoid setting up individual rules to translate each organization. Use a naming convention that allows you to rely on an Else rule for this translation table.

Some schools find it necessary to distinguish their subject/department codes based on institution or campus code. (For example, MATH-FLA and MATH-CIO.) This requires creating multiple distinct organization records in 25Live.


Depending on your SIS type, there are two ways that LYNX can translate location names:

  • Finding an exact match with a facility record in your SIS
  • Combining the facility's room and building code into a single field

If you use the second option then LYNX only translates the building code, leaving the room code untouched. It joins them together with a "delimiter" (such as a space or underscore) chosen elsewhere in your configuration, then looks for a location whose name matches the whole thing. Because LYNX doesn't translate the whole name, the preview of translated results does not include a "Valid" column.

Time Zone

Most customers don't need to worry about this, but some schools have multiple campuses spread across the country or the world. This translation table is for them.

Since meeting patterns in the SIS don't include time zone information, there's no difference between a 9:00 AM class in New York and one in California. If you try importing them both to Series25 this way, it will produce undesired results whenever anyone compares the two classes in 25Live or a published calendar.

This translation table lets you pick which time zone each campus belongs in, then automatically converts each event's time as it is imported. The end result is that everything will look correct based on a user's personal time zone settings on their computer.

Instructor Contact Roles

The 25Live event description always contains instructors' names, but you may also choose to add instructors as contact roles. This allows you to search for them by name and use back-to-back binding (link).

By default, LYNX maps all SIS instructor roles to the default 25Live contact role named "Instructor". Since 25Live only allows one person to be in a contact role at a time, this presents a conflict when a section has multiple instructors in the SIS. If there are multiple instructor roles on a section and they are all mapped to the same 25Live contact role, LYNX makes an internal assessment of which instructor is the primary one, then adds that person to the event and ignores the rest. (They are still added to the event description.)

We recommend that you customize this translation table and set up separate rules for each instructor role in your SIS, mapping each one to a separate contact role in 25Live. This is the best way to guarantee that the right instructor ends up in the right role.

Optimizer Data (Feature Preferences and Partition Codes)

Details of the Manage Schedule25 Optimizer Runs page

By adding pedagogical requirements to your sections in the SIS, you can influence the Optimizer's behavior. These come in the form of section requirements (supported by most SIS types under various names, and imported to 25Live as location feature preferences) and partition codes (supported by Banner). For more information on these effects, see Optimizer Setup (link).

Feature preferences often have very different naming conventions in 25Live than their counterparts in the SIS. While it is convenient to rely on an Else rule to match them together, sometimes this creates an undesirable appearance. It may be some extra work to create a bunch of individual rules for each section requirement, but it often pays off in readability.

Partition codes set via the SIS are a legacy configuration that CollegeNET no longer recommends. You'll find it much more effective to manage your partition preferences in 25Live for an entire organization at a time.

You also have the option of using a separate translation table to map section requirements to event categories. This does not affect the Optimizer, but it can be useful for creating searches.