Hi Arosha,

This message occurs during a normal import. If there are any instances that have been updated in the target environment (QA) that have not been updated on the Source system (Development), it will present an "aged update" error. There are two ways to address aged update errors, in general. If you, I recommend the second approach.

1. If you know that the most up-to-date information is in the Source system, you can override the "aged update" error by manually importing.
   1. Sign in to the target system (QA)
   2. Designer Studio menu > Application > Distribution > Import
   3. If you have a single-node system (or you are lucky) you can choose "File on server" and choose the archive with the build number in its name. If you have a multinode system, you'll have to go get the archive from your repository and manually import it.
   4. Click next through the import process. Read all screens carefully and make sure you understand why your data or rules have been updated more recently on QA than in Dev.
2. In the case that this is data and that data should not be packaged and migrated. In your case, the cause is as follows: When users log in, they are updated. So, if a user logged in more recently to QA than Dev, you will have an "aged import." This means that you don't want to migrate users from system to system because they will probably cause aged update problems. Also, it could be a security concern.
   1. Open the Operator ID in Development
   2. Click on [Edit] next to RS: in the Operator ID ruleform header
      • If there is no RS in the header, it may be in the Product rule.
   3. Remove the RuleSet
   4. Click Save
   5. Kick off the build again

Side note, the user who is identified in the Authentication profile (in your case AdminSSR) can not be packaged and moved with the pipeline because that user will cause aged update errors 100% of the time.

Thanks,
Dave