Deleting and Archiving Extract Sets

When you've finished working with an extract set in LYNX, you don't want it hanging around forever. At best it clutters up your list, at worst you might mistakenly click it and import something you didn't mean to. In this situation you have two methods for dealing with an unwanted extract set:

• Delete the extract set to remove it permanently, potentially deleting events from 25Live
• Archive the extract set to hide it away and leave 25Live events unaffected, with the potential to unarchive it later

Both of these options are available in the More Actions menu below an extract set.

When should I delete or archive?

Follow this simple guide to recommend which action you should take when you're done with an extract set.

How do I unarchive an extract set?

If you want to restore an extract set from Archived status, follow these steps:

1. Check the Show Archived Extract Sets box under the list of extract sets
2. Select the extract set you wish to restore
3. Click More Actions > Unarchive from the row of buttons below
4. (Optional) Edit the extract set to make it Active again so it can receive automatic updates
5. (Optional) Manually import the extract set to make sure all its contents are up-to-date in 25Live

Why does deleting an extract set remove classes from 25Live?

When you delete an extract set, it's gone for good and there's no way to get it back. When you archive an extract set, it's inactive and hidden from view unless you check the "show archived extract sets" box, at which point you can unarchive it.

This difference is most relevant when LYNX tries to "clean up" 25Live data, whether initiated as a manual process or as part of a regular import. As part of this cleanup, LYNX removes anything from 25Live that doesn't meet the criteria for any import extract sets. Here's the logic behind this:

• If it doesn't meet the criteria for an import extract set, then it can't be imported.
• If it can't be imported, then it shouldn't be in 25Live.
• If it's in 25Live when it shouldn't be, then it should be deleted.

This process is easy to think about in terms of sections whose data changes in your SIS. Say you want LYNX only to import classes that meet in person (Instruction Code = P). You don't want 25Live to contain any online classes (Instruction Code = O). You set up your extract set criteria so that only P classes are imported, and everything's good. But some time after that initial import, a class changes from in-person to online. As an O class, it no longer meets the criteria for the extract set. Rather than force you to hunt it down in 25Live and remove it, LYNX automatically deletes the event.

Now apply that logic to deleting an extract set. Suddenly an entire term's worth of classes no longer meet import criteria, because all criteria have been removed. LYNX does its job and deletes everything that "shouldn't" be in 25Live, and now an entire term has been wiped out.

Archiving an extract set saves you from this scenario because it still technically exists. Inactive extract sets don't trigger LYNX's cleanup protocol, and archived sets count as inactive.  That's why archiving an extract set for an old term is the way to go when you want to keep your data in 25Live.