Jump to content

Is customer email suddenly unique? [Urgent and Blocker]


HHH

Recommended Posts

@Gerry @Daniel Dekel

The patch and setting to disable the check, provides a work around, but there is still the issue that if you want a contact to have an individual primary email address, but use a common (alternate) email address for email notification purposes.

Are they any plans to provide this sort of functionality? As this way the contacts could still use their individual primary email addresses as their login id, but emails are sent to the common one.

Cheers

Martyn

Link to comment
Share on other sites

@Martyn Houghton

In my previous comments above I said
 

Quote

So we are going to look at changing this such that the LoginID WILL BE unique and is the only thing you can use to log in with, this Login ID field can in fact hold an email address so if you want the convenience of being able to login with an email address which is a good option for most people, but you will be stuck with the fact that login ids have to be unique.  The current email address WILL NOT BE unique, that will be what is used for email communications for contacts. 

which will deliver what you are asking for?

 

Gerry

Link to comment
Share on other sites

@Gerry

I was referring more to your the other comment (below), where the user primary email address would be unique, but the contact one is not.

"From what you are saying I think the best option would be to allow a contact to have a notify email address which would allow duplicates, that is distinct from their primary email address which would not allow duplicates.  Does that make sense?"

Ideally we would want the contact primary email address and the login ID to be the same and unique, but the option for the alternate email field which is already present to be enabled as the email address used in notifications etc, where enabled on a contact by contact basis.

Cheers

Martyn

Link to comment
Share on other sites

@Martyn Houghton

Thats what I am saying.  The Login ID would be unique, and it should be an email address, that would be the contacts primary email address.  The current email_1 address would be the notify email address, that would (as it currently does) allow for duplicates, but that would also no longer allow the email address in that field to be used as a login ID.  Are we saying the same thing?

Gerry

Link to comment
Share on other sites

@Gerry

Not quite, we would want is h_email1 and the Login ID to be the same personal identifiable email address and the h_email2 (Alternate Email Address) field to be used when email is sent via connections or BPM notification nodes.

In essence you have a radio button on the contacts profile for them/us to set which of the two email addresses they want emails to be sent to.

This way email matching in the mailbox to contact will still continue to work when the customer send an email, from there personal email address, but the customer common email address is the one emails are sent too.

Using the common email address in h_emial1 will mean you cannot match incoming emails to individuals.

Appreciate this is a more involved change due to the different touch points, but in essence would mean you can use both approaches depending on the business requirements.

Cheers

Martyn

Link to comment
Share on other sites

@Gerry

Historic basically, we migrated are large number of login id from our previous system into Support Works and then on to Hornbill, which are not email address based.

We currently have 10,876 contacts with a defined value in h_logon_id and of those 10,801 do not contain a '@' symbol in the value.

Cheers

Martyn

Link to comment
Share on other sites

@Gerry

Customer login with the Legacy ID held in h_logon_id column at the moment, but we would like to move people to using their personal email address, but this is where we fall foul of the issue where sites what to use a generic email address for a number of individual accounts for notification/emails.

Also as we cannot uses Sites for contact/organisations, we have to have separate contact records for the same person with the same email address but a different logon_id for the each site they support in their shared services setup.

Cheers

Martyn

Link to comment
Share on other sites

@Martyn Houghton

Thats exactly the problem though, you cannot have shared login ids, even if they are emails.  So every contact has to have a unique login ID, so that can be their personal email address, if they do not have a personal email address then that can be anything else you like so long as its unique in the database.  Then the notification email address h_email_1 does not have to be unique. 

So in your case, you would update login id with the email address, except for where its a shared email address, in which case you would leave what is already present in the login id field?

Thats a relatively simple data migration I would have thought?

Gerry

Link to comment
Share on other sites

@Gerry

The main issue I see with this is by having the h_email1 as the shared/non unique email address, email sent into the shared mailbox from the individual's personal email address, would no longer match, so you would not be as easy to log a new request from email without having to search manually for the individual contact. Unless you are are saying the email matching in the shared mailbox also takes into account their alternate email address h_emial2?

Cheers

Martyn

Link to comment
Share on other sites

@Martyn Houghton

Yes thats a good point, and I think the email matching would have to match against both fields. Of course this its self presents a challenge because if it matches where there are non-unique emails, you then need to add a whole new UI just to deal with selecting the right one - I expect this is probably already implemented though...

Gerry

Link to comment
Share on other sites

  • 1 month later...

Hi @Daniel Dekel, I saw on

 it said "Added a new System Setting api.xmlmc.uniqueUserHandle.enable, setting this option to false allows duplicate handle/display name for the user(s)."

Is this same as the patch you were offering back in March? Our setting for api.xmlmc.uniqqueUserHandle.enable is 'on' and I presume to allow duplicate name import we should set that to off?

Thanks

Claire

Link to comment
Share on other sites

  • 3 weeks later...

@Claire Holtham, sorry I did not see your message before.

To the answer, no. The setting "api.xmlmc.uniqqueUserHandle.enable" was not the one set in the patch. This setting would allow when importing from LDAP to add duplicated handle names in users.

To disable the unique handles, you need to set this to OFF (disable).

Hope this answers your question.

Regards,

Daniel.

Link to comment
Share on other sites

  • 2 weeks later...

Is there a negative impact to setting this off (api.xmlmc.uniqqueUserHandle.enable) - when we started with Service Manager I don't think this setting existed or was enabled. I'm now finding issues with our LDAP import where new customers didn't get created (due to having a duplicate handle). I'm also seeing errors were existing staff (with duplicate handles) are having issues raising tickets via the customer portal eg. if there are two Nasim Gani handles (with different login id's) one of the accounts can create request, but the other can not.

I think disabling this setting will solve both issues but wanted to make sure I'm not introducing something new.

Nasim

Duplicate Handles.PNG

Link to comment
Share on other sites

Thanks @Harry Shah

I'll disable the setting - but may raise an incident as it sounds like we shouldn't be getting an error with duplicate handles (unique log in id's).

Nasim

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...