Expiring memories
Set a memory to stop applying automatically once it's no longer true.
Some facts about your MSP or a customer are permanent. Others are only true for a while. Expiration is how you tell Uniportal which kind you just wrote, so a memory that's past its shelf life stops shaping what the AI does, without anyone having to remember to go delete it.
Setting an expiration
Memory expires is an optional field on the create and edit forms, below the scope and the always-applied/when-relevant choice. It's blank by default, shown as "No expiry. This memory is permanent." Set a date and Uniportal stops using the memory once that date passes. See Creating memories for the rest of that flow.
Why give it an end date
A memory without an expiration is treated as true indefinitely, which is right for most of what you'll write: a customer's infrastructure, a device's quirks. It's wrong for anything with a known end point.
For example: Pam Beesly is out until October 15, route any approvals that would normally go to her to Angela Martin instead. That's worth the AI knowing while Pam's away, and worth forgetting the moment she's back, otherwise the AI keeps routing around someone who's sitting at her desk. Set the expiration to October 15 and it stops on its own.
A migration window works the same way. The workaround you told the AI about during the cutover stops being true the day the project closes out, so give it the same end date as the migration instead of trusting someone to notice and clean it up.
Without an expiration, a temporary fact only goes away if a human remembers to archive it. With one, Uniportal does it on schedule.
When to skip it
If the fact has no known end date, Dunder Mifflin Scranton's change window isn't going anywhere on its own, leave expiration blank. Adding one to something permanent just means the AI quietly loses real knowledge on a date nobody meant to matter.