Print a list of users in ECE 12.6.1.3

[leigh.stavinoha]

Does anyone know how to print out a list of users in ECE?  I need to compare them with a list from our other call center programs and cannot see where to do that?

Thank you!

[david.macias]

There's an API which might help though I've not tried it (https://pubhub.devnetcloud.com/media/enterprise-chat-and-email/docs/guides/interaction-api-developer-guide/da/d1e/classadministration_1_1pages_1_1user_1_1_user_search_page.html#v12_admin_users_search_page) I would look at the EGPL_USER and EGICM_USER tables though.

david

[bill.king1]

Can you not use the list of users from UCCE?

[leigh.stavinoha]

Yes, that'll work, thank you!!

[leigh.stavinoha]

One more question please.  Do you know.  If a user in UCCE does NOT have an ECE skill group assigned to them, can they still log into ECE and receive emails?

[david.macias]

I've never tried it, but I can't see how they would take an email if they don't have a skill that handles email.

david

[leigh.stavinoha]

I just tried it.  It won't work.  I'll remove those users from UCCE.  Thanks everyone for your help!

[bill.king1]

If you're just trying to get a simple list of users, if you don't want to delete those non-ECE ones, you could always do something like use a different description for those agents, and then just query for the ones that don't have "Non_ECE" or whatever in the description.

[leigh.stavinoha · Accepted solution]

I've created a query that will show me who those users are. Thanks so much for your help!!!

[david.macias]

How about sharing the query to help the world?

david

[leigh.stavinoha]

I have this query that will Identify all users that have the skillgroup for ECE:

select b.EnterpriseName as 'Agent Name', c.EnterpriseName as 'SkillGroup' from t_Skill_Group_Member a, t_Agent b, t_Skill_Group c
where a.SkillGroupSkillTargetID In ('7112','7113','7114','7115','7116','7117','7124','7125','7126','7127','7128','7129','7130','7189','7622','7909','8250','8576','8657')
and a.AgentSkillTargetID = b.SkillTargetID and a.SkillGroupSkillTargetID = c.SkillTargetID
order by AgentSkillTargetID

For NOW, I'm going through each one and comparing them to our AD and removing them manually.  Then when we remove everyone from ECE later this year, I'll run this query again and mass remove everyone in ECE.

[bill.king1]

What are you comparing against AD? I only ask because if you're looking to see if they're active or something, you may find it easier to do it the other way. For instance, you could get the list of users from AD and run it against UCCE (assuming you use same login name format) and those that don't exist, you know you can delete.

[leigh.stavinoha]

So, I work for the state.  I don't have access to AD other than someone running a report for me, and I can get the user information from the Outlook address book. I can't have AD compare it to UCCE as they're not connected.  And that's why it's taking me so long to go through the list to remove everyone that's gone.  BUT, we're getting rid of ECE in June and I'll be able to run a script in UCCE that shows everyone that does still have a SG for ECE and I will remove them all at once.  The big problem I'm having is that we have a bunch of users in UCCE that do NOT have a SG for ECE, so they cannot even log in.  They've probably NEVER logged in, as they would have had an error message.  I'm cleaning out the termed employees and anyone who doesn't belong to a team or has an SG.  Then in June it'll be easy-peasy to remove the other ECE peeps.  If that all makes sense.

[bill.king1]

Hi, that's what I mean though, if it helps, you could get the list of users with AD accounts from your contact, and you do the export of all users in UCCE (whether ECE or not) and compare them. Anyone that is on the UCCE list that doesn't have an AD account, I'd imagine you could deactivate/delete.
Another thing you could do is deactivate the non-ECE users you mentioned in UCCE, but don't delete them yet. That way if it turns out that they do use the system on occassion/did in the past/etc., you don't lose the reporting and it would be easy for you to re-enable the login if needed without having to redo the entire profile.
Hope that helps as far as potential business process.