My Team is opening a new building this year and retiring two others. I was wondering how to handle removing the old locations properly when it comes to assets and users.
I have figured out how to set all users to migrate with our SSO to the new location along with any of their assets updated through a google or microsoft sync. I also have the new buildings room data filled out, but is there any other actions that need to be taken when it comes to opening and closing a new building
Thankyou
Page 1 / 1
@DKelly 430e93d tonacsd Thank you for submitting your question to our Community!
If you have any permissions or rules based on location, I would check those.
Additionally, you can delete locations if you would like to, but you could rename them instead to identify the location as decommissioned.
As a precaution, you could set up a rule that if an asset or ticket is assigned to those locations, reroute them to be assigned elsewhere!
I hope this helps
Hello @Kathryn Carter ! We are currently in a similar situation, we are undergoing a reorganization of our communities, which are listed as locations in IIQ with Azure groups that feed into each location. We have 2 new locations to be added and 2 to “remove”, and we are wondering what's the difference between decommissioning a location vs. renaming the location? How does this effect historical ticket data? How will the data show up on a report?
If we renamed a location, we could just move the groups accordingly.
Thank you!
@Erica If you just rename the location, all the information associated with that location will stay with that location. However, if you decommission a location, the information will stay with the decommissioned location. You could bulk transfer tickets and assets to the new location.
Thank you, @Kathryn Carter. To clarify, if we rename a location, would old tickets show the updated location name? Or would they show up under the old location name?
By decommissioning the location, it sounds like old tickets would still show up under the decommissioned location.
Thank you!
@Erica They should show up under the new name since it is the same place, new name.
@Kathryn Carter - once a location is Decommissioned/Retired, tickets can no longer be created for it and assets can no longer be updated to it, correct?
Also, does anything happen to tickets in an open state if that location is retired?
@Erica I was actually mistaken above, the update is not retroactive, so the old tickets would reflect the old name.
The tickets are in an open state when the location is retired, will be relocated to another location
@Kathryn Carter - once a location is Decommissioned/Retired, tickets can no longer be created for it and assets can no longer be updated to it, correct?
Also, does anything happen to tickets in an open state if that location is retired?
I’m actually working on this as well. I set a location to “Decommissioned/Retired”, and it still shows up in the location list when creating a new ticket. So I don’t think that field really does anything other than inform you of it’s status... For us, we want to keep record of the location and it’s ticket history, but not allow new tickets to be created for it by mistake.
@jclark16 - We have discovered this as well. Changing a location to Decommissioned/Retired did not do much. It was essentially still available and useable. To combat this, I adjusted the names of the old locations with the naming scheme: z_Location Name, so that it drops to the bottom of the location list, and also adjusted all custom permission policies to deselect Agent's abilities to Create tickets, assign assets, Import etc. at the retired locations. The retired locations still show up in the list, but if an Agent were to try to create a ticket, they receive an error message.
@jclark16 I would say that deleting the location for that workflow. It will reassign tickets that are still open.