We have had turnover in our Company and our Dev Team are looking at several hundred Orchestrator assets, as well as numerous jobs that have not been run for a significant period or have been disabled.
Does anyone have a recommendation for identifying assets (or packages) that are candidates for archiving?
I don’t think there is a nice way to go about this. For example Assets don’t have an attribute in the database for last accessed time, and out of box I only see Create/Delete/Modify actions in the audit log.
You might be able to bump up the log level for a period of time to try and determine which assets are being called, but that still runs the risk of items that are called less frequently not being flagged.
If I were having to go through these motions, my check list would most likely include
- Get base list of all assets across Tenants and Folders (Modern Folders allow sharing/linking of assets)
- Scan/Sniff the code base for Asset usage (This should probably be the most revealing given the right code repository or Find Tool/Command), worse case you download the actively deployed package and scan that.
- Review existing documentation (Solution Design, Deployment MOPS, Test Evidence, etc)
- Develop a migration plan, move one process at a time from existing Folder/Tenant into a new Folder/Tenant Regression testing as you go… rule of elimination anything left over…
As for Active/Disabled Triggers/Processes you’d want to review your Job Logs which can be done in the Jobs or in the Tenant > Audit. As you’ll not only want to look for Triggered Jobs but also Adhoc Jobs kicked off by Orchestrator Users and Attended Users. If you have your Orchestrator and Robot logging being directed anywhere else UiPath Insights, Splunk, etc. this would be another option.
Thanks. I think we’re heading down the track you’ve identified.
We queried the database and bumped the asset list up against the activity logs (30 days to start), and parsed via the “/” and "_"separators, which will allow us to focus on key words.
We have decent discipline in terms of Process_Environment, a little less so on Assets (that will change going forward).
No, not a nice way out of the box to go about this. We will divide and conquer by environment and the pain will be somewhat reduced. Thanks again for the response.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.