Set Expiry Date for User Account

[YvesLeger]

We have contractors to whom we want to provide an AGOL account with access to our organization's content for a specific period of time.  We now have to manually delete their account after their contract is done.  It would be nice to be able to set an expiry date on their account (not just on the password).

[Wei-HsinFu1]

We have students using our organizational ArcGIS Online account for just a term.  It will be great not have to keep track of this type of accounts and manually delete them. 

[Anonymous User]

Hello Yves Leger,

Would an account becoming disabled after a specified period of time be satisfactory? 

"Disabling a member prevents the member from consuming organizational resources. This can be useful while you move their items to a different member. Disabled members cannot sign in to the organization, consume organizational resources, create content, or administer the site. They are still members and count toward the number of users in your organization. Disabled accounts are automatically disabled for Esri access."

Manage members—ArcGIS Online Help | ArcGIS 

Is the intent in setting an expiration date on an account to prevent the user from accessing the organization or to automate the removal of the named user and their content from the organization?

[HilaryCampbell]

Hi, Katie.  I'm not sure what Yves' intent was here, but we certainly have the same question.  The main intent of applying an expiry date to a named user account would be to free up that account for another user, as the total number of named users in our organization is very limited.  A key piece of that would be to prevent that user from accessing the organization after their work is complete, as you suggest above.  As for the content of expired user accounts, perhaps an automated message to the AGOL organization's account administrators two weeks before the set expiry date would provide enough time to permit any content to be moved to another user account or deleted as required.  However, if a user is set to "Viewer Only", this would not be necessary as that user would not have any content.

This would go a long way towards helping AGOL administrators keep their corporate accounts "clean" and to ensure that they are getting maximum benefit from their allocation of named user accounts.  Applying an expiry date which would disable a user account is definitely an option, but that could also get messy over time.  Administrators still have to go through the corporate account and manually delete disabled user accounts.  Perhaps setting a default expiry date of 6 months from the date an account is disabled would do the trick...?  As we progress with AGOL, our accounts are going to become more and more complicated.  Anything we can "set and forget", so to speak, makes our day-to-day jobs that much easier, and much more predictable for everyone because it would become a standard.

Any suggestions or questions most welcome.  Thanks!

[YvesLeger]

Katie,

Yes, the intent would be to automate the removal of the named user and prevent them from accessing organizational data once their contract is up.

[MegHoole]

I like this idea... I'd add that I'd like have an option that the accounts to be flagged for review rather than auto disabled or deleted.

[ChrisArneson]

I was researching this same functionality.  We want to give external entities access to our ArcGIS Online maps but only for a limited time.  It would be fantastic if we could just create temporary accounts/passwords which expired after a set time period.

[MōnoSimeone]

This idea needs to be implemented, I'm glad to see it being reviewed!

A few additional feature enhancement comments:

1) The expiration date parameters should be tied to a Role, such as "Student" so that all users assigned the role automatically get an expiration date; and admins have the ability to modify a individual manually, if necessary.

2) There should be options for implementation: End date only; Start and End date; or Duration (for next 6 months from Start date)

3) Options for when end date arrives: Disable vs delete (considerations for deletion, all items move to admin or are also deleted)

4) Notifications:

- Provide an email notification template wysiwyg view so admins can include important information about who to contact, methods to migrate content, recharge information, or other messages "after 60 days of account being disabled, this account will be deleted and all items X." And, option for the admin to receive a copy of email.

- The ability to set notification interval, so messages go out on 60, 30 14, 7, 0 days prior to disable/delete. End-users need be made aware several times, the last thing I want are users complaining they didn't get a notification.

5) Ability to search/filter users by active/disabled; or when accounts expire.

[Dr_Carter]

Same here. We have an education license and need to add and remove hundreds of students each semester. An option to have their accounts expire at a set date would help a lot.

[HilaryCampbell]

This issue has been around for quite a while now.  I spoke about this with Kelly Gerrow at the AGOL island at the UC last week.  We talked about what types of users could be automatically deleted, as well as what could happen with user accounts which are automatically disabled on a specified date, instead of deleted. I suggested that users who did not create any content in their accounts (our org has a lot of read-only viewers) could be deleted outright. User accounts which do have content could be disabled, which would allow the account administrator(s) the opportunity to move that content to another location before removing the user from the account. Either option should free up the use of that identity. For organizations with a finite number of named user identities in high demand with frequent turnover, the disable option would be very attractive: the quota of named user identities assigned to an account should not be impacted by disabled identities.

Making administrators responsible for checking who is doing what and who is finished when is not optimal. There has to be a better way. Whether for student placements or term contracts, projects or short-term initiatives, AGOL administrators need the ability to set an expiry date on accounts.

I’d also like to suggest that identities are frequently assigned to people who never use them, in anticipation of a perceived need which is never realized. The administrator should have the ability to set warnings for unused identities, with an option to send users system-generated notice that their accounts will be disabled if the account is inactive for a defined period of time (e.g. 90 days).  Admins would also need an easy way to find/filter on disabled accounts and accounts nearing expiry.  I love Mōno Simeone's idea of tying an expiry date to a role.

bulk administration‌  expiry date‌ ArcGIS-Online‌ #named users‌ #AGOL_identities‌

[MōnoSimeone]

An aspect of this discussion that should be raised is whether or not to use the built-in accounts vs Enterprise Single-Sign On. When implementing SSO there are functions and scripts that can be used to automate how a new user is added into the organization such as their role, credits, groups etc. Esri has made the integration with SSO much easier with more improvements coming (supposedly) by the end of the year.

The reason I raise this is for two parts: 1) with SSO, there is no need to manage new users, an account is automatically created with assigned credits and group access when they sign-in for the first time; 2) Anyone interested in SSO should contact their Esri rep about "functionally unlimited users" which could mean admins not being constantly worried about named user caps -- for some institutions this approach may alleviate the need to delete accounts for students/faculty that have moved on, therefore eliminating the need for an expiry date as well as eliminating the need to deal with content that is connected to maps and apps. That being said, I still believe an expiry date is highly desirable feature that should be implemented whether an org chooses SSO or Built-in accounts.

I think there are still some technical issues and best practices that need to be fleshed out but considering the information I've learned this past week I will strongly work towards implementing SSO to reduce admin workload.

Re: content in a disabled/deleted account > consider an "archive" named user and move content to this account, individual folders can be made labeled with username for easy search.