Transferring Ownership from a Departing GIS Lead
Coastal Regional Council's GIS lead retires in three weeks. She owns 420 items, including 18 hosted feature layers used by nine public web apps, three scheduled notebooks, seven groups, and two Experience Builder apps. One hosted feature layer has 1.2 million parcel records and is edited daily by six staff. Two of the public apps are embedded on the council's website and cannot be offline for more than 15 minutes. The incoming administrator has been in the role for two weeks and has Creator privileges but is not yet an administrator. The organization has 60 members; only two other members have Creator user types, and neither has managed scheduled notebooks. The finance office requires that credit-consuming notebooks continue to run. The retiring lead has agreed to help for five business days only. The administrator must move ownership and keep production services and public apps working.
1. What inventory and dependency work must happen before any ownership transfer?
Read the worked answer
First make the incoming administrator an organization administrator; Creator privileges are not enough to reassign ownership or see all items. Then inventory the 420 items by type, owner, sharing level, and dependencies. Use item dependency views to trace each of the nine public apps back to its web maps and hosted feature layers. Identify the 18 production layers, the six staff who edit the 1.2 million-record parcel layer, the seven groups, the three scheduled notebooks, and the two Experience Builder apps. Rank by public impact: the two embedded apps and their layers first, then daily-edited layers, then notebooks, then archival content. Confirm which items are shared publicly or to groups and which groups the retiring lead owns. Do this with her while she is available, because undocumented dependencies are the main risk.
2. Recommend the transfer sequence and the checks needed before the retiring lead's account is disabled.
Read the worked answer
Create a named successor owner or use the incoming administrator; avoid a shared generic account for daily ownership. Transfer the production hosted feature layers first, then their dependent web maps and Experience Builder apps, so the chain remains coherent. Transfer group ownership and keep group sharing unchanged; check that public sharing is preserved. For the notebooks, transfer ownership and then open each schedule to confirm it still runs under the new owner; if the schedule cannot be transferred cleanly, recreate it and test a manual run before disabling the old account. Do not disable the retiring lead until all nine public apps have been tested in a private browser window and the six editors have made a test edit. Because item IDs do not change on ownership transfer, embedded URLs should remain stable, but verify them directly.
3. What are the highest-risk failure points, and how should the administrator mitigate them during the five-day support window?
Read the worked answer
The main risks are an unowned scheduled task, a group with no owner, and a public app whose layer is shared only through the retiring lead's personal content. Check for items shared only to a group she owns; transfer the group before the account is disabled. Check credit-consuming notebooks for stored credentials or connections that break under a new owner. Confirm the two other Creator members can support the transition; if not, the incoming administrator should temporarily own critical items. Keep the retiring lead's account active but sign-in disabled until the five-day support window ends, then disable it. Record the transfer in a runbook so the next departure is not a crisis. The five days should be reserved for dependency checks and public app verification, not for discovering unknown production items.