Has anyone found a way to control users' ability to change their email address in their profile?

We are finding that as people log in for the first time if they are a chrome user chrome is autofilling the email address whithout them realizing it. I have had the same issue with setting up new users and getting errors that the email addres is already in use to find my personal email in there instead of what I typed initially (I have myself set up as a reviewer for testing purposes). We try to alert new users as part of our set up process to watch out for it.

Any additional thoughts on how to stop users from changing their email addresses or changing it back immediately once changed? I’m thinking of using Fusion.

Hi Leif, that is an interesting topic indeed. As far as I am aware, it is pretty common practice to allow an end-user to change their email address in a given system. But perhaps the real desire is to truly enforce that user email addresses are in a set of specified domains.

To your point, Workfront Fusion could be utilized to reasonably enforce this rule or similar ones.

I've setup a simple example wherein I am initiating a scenario (in Fusion 2.0, but could also occur in 1.0) based upon looking for changes to email addresses (Watch Field Module), then simply performing an update to the user to set their email address back to what it was previously. (Update Record Module).

In this instance, it's very important to include a special filter between the two modules which looks to make sure the "Last Update By ID" is not equal to the User ID that is assigned to the "Fusion user". This prevents you from entering into an "infinite loop" (e.g. look for changes to email address, find one, update email address, that counts as a change to an email address, so it updates again, and so on).

See attached screenshots for an overview of what the scenario looks like.

Hi team,

Glad the Fusion details were useful for the original post. And thanks for the feedback.

I'm not as familiar with the teams discussion that Narayan raised, but my initial testing appears to confirm that any user on a team can delete that team. I'm going to engage our product manager over this area to discuss and perhaps he/she can engage in this thread or a thread about that topic.

Cheers.

Hi Leif,

To your original “users can change their own emails” concern...

One easy way to detect non-standard email accounts would be to create a User report that filters for users whose emails do not match yourdomain.com, like this (shown in textmode):

emailAddr=@yourdomain.com

emailAddr_Mod=cinnotcontain

You could put that report in a prominent place (eg shown upon login) to increase awareness, but it is obviously a reactive approach.

If you need more control (even if it is just the threat of “inconvenience”), you could use our UberCalc solution (or Fusion, or the native API) to then disable any account that does not match yourdomain.com (eg upon SysAdmin “button click”, or ‚Äî even more stringent ‚Äî- on some schedule). Users who change their email (against your company policy) would then be locked out of Workfront until it is reinstated (with “re-education” of the rules) along the way. Happy to chat further via doug.denhoed@atappstore.com.

As for the deletion of Teams, although I can’t think of one, if there is a usecase that does support the need for any team member to delete teams of which they are a member, perhaps (similar to “Never allow users to delete announcements”) under a Layout Template’s Additional Restrictions, an option for “Allow users to delete teams they are on” (default false) could be added, with the current default behavior reversed (ie so only SysAdmins, and perhaps GroupAdmins can create and delete Teams).

Regards,

Doug

Sure thing. See attached.