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

[LeifBr2]

Our controls team is having trouble accepting that users have the ability to change their email address on their Workfront profiles. We currently have SSO enabled. As a system admin, they want me to find a way to mitigate either through Fusion or reporting. I wanted to know if others have faced this challenge and what, if anything, were you able to do to mitigate.

[PaulaKo]

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.

[LeifBr2]

Thanks for that feedback. Yes, we want to keep it with their company email. Once they change it to their personal emails, it causes a control problem.

[LeifBr2]

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.

[NRYNR]

Hey Leif, I’m also interested in hearing what others have to say about this. It concerns me that my users can change their own email addresses. Let’s say someone thinks it would be cool to change it to billygates@microsoft.com. Wouldn’t all of the user’s communications, sent reports, confidential data, perhaps even password reset links go to Billy from that point forward? I don’t think that’s a good thing, but I might be missing something.

[darin_patterson]

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.

[NRYNR]

Hi Darin,

While I'm sure customers with Fusion appreciate the advice, I'd like to know what you suggest the rest of us do? At Truist, I can only hope that users don't figure out that they can change their email addresses or that they can delete that team they're on that I've set as the default route from a queue's routing rule.

I feel this capability falls into a category of things every customer needs whether they know it or not. Along with some controls around team administration plus a few other tweaks and bug fixes, it would be nice if we could see these needs identified and perhaps added to a "Classic Fixer Upper" project to resolve some issues. I suspect this approach would keep most of us Classic customers happy, plus it sets a good precedent for functionality that is also needed in New Experience. It's a pandemic and budgets are all but gone so it might be a good time to be frugal and tune up the car.

Thanks,

Narayan

[CalvinFold]

After reading Narayan's reply, I had to go check our instance.

Any user can delete a team!?!

WF does realize that teams can be an integral part of a request queue and routing schema, correct?

Considering how many other objects are "owned" in WF, I'm really surprised teams don't have an owner that would be the only person who could make changes.''

I would honestly consider this a bug that an admin could create a team that anyone else could edit without permission.

Darin, please tell me there is a way to lock-down teams?

(I was annoyed enough that any user, at least planners, can create a team. This made a huge mess early on in our instance. But having admin-created teams removed or edited could make a big mess of our request process.)

[LeifBr2]

First off, thank Darin for your reply. That was super helpful. I will forward this on to my team.

I agree that this should be out-of-the-box functionality. Controls team is beating us up over it.

I am very curious about the users can edit their teams. I thought this is something we can take away for users so that teams is something they cannot edit. That's how we managed it. Am I missing something?

[LeifBr2]

Thanks for this reply. Do you also happen to have the update screenshot? We are working on trying your solution and got stuck on the update details. Thanks!

[darin_patterson]

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.

[Doug_Den_Hoed__AtAppStore]

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

[darin_patterson]

Sure thing. See attached.