ServiceDesk

 View Only
Expand all | Collapse all

The specified Primary Contact does not exist in the Portal.

  • 1.  The specified Primary Contact does not exist in the Portal.

    Posted Jun 27, 2011 03:13 PM

    I keep getting this error, "The specified Primary Contact does not exist in the Portal. Please try again or search for a user." when adding a contact to a ticket. Does anyone know how to fix this?

    Thanks

    Jen

    Contact search



  • 2.  RE: The specified Primary Contact does not exist in the Portal.

    Posted Jun 30, 2011 03:17 AM

    Did you Sync with AD? Can you actually see that user you searched for listed under Users in the Admin Page ?



  • 3.  RE: The specified Primary Contact does not exist in the Portal.

    Posted Jun 30, 2011 02:50 PM

    Yes I have done a AD sync. Yes I can see the user in the All users list.



  • 4.  RE: The specified Primary Contact does not exist in the Portal.

    Posted Jul 28, 2011 10:09 AM

    We sync SMP against AD & have over 25k users since we're an educational institution & include student accounts. The issue we've seen has to do with the array used in the SD.Feeder.TechnicianIncidentForms when you're going to submit the ticket. There is more than one array but the last one is the issue.

     

    Here is the location of the array in question: Form Validaion (1.46) -> SearchUser (6) -> Max Results: value : 5 (we changed this value to 100 to match the other arrays)

     

    In our tests, we found that the array is populated again before the ticket submission, but only allows for 5 matches to the username. It doesn't match the username exactly, so depending on the amount of users you have, you may have more than 5 matches for the particular username. If the username isn't in the top 5 results, then you'll get an error that the user isn't in the portal when in fact they are. We're looking to change to logic to match the username, since at the point of ticket submission, we already know the username.



  • 5.  RE: The specified Primary Contact does not exist in the Portal.

    Broadcom Employee
    Posted Aug 02, 2011 12:19 PM

      



  • 6.  RE: The specified Primary Contact does not exist in the Portal.

    Posted Sep 27, 2011 07:26 PM

    I added the user manually. I have AD syncing fine and when I click on the mangifiy glass the search user field will come up. I get the error when clicking on the Check if user exists.



  • 7.  RE: The specified Primary Contact does not exist in the Portal.

    Broadcom Employee
    Posted Sep 28, 2011 05:57 AM

    Sorry for asking vaguely, what I meant was, how do you reach the situation on the screenshot? If you type 'user' into the field and click 'Check if User Exists' button (the one with person and checkmark), this result is expected. If you look at the workflow behind this button, it searches for user by e-mail address field, using the contents of that field.

    The intended usage of this functionality is to click it after entering full e-mail address of user. If the user with such primary e-mail address exists in the Process Manager database it will be set as primary contact. If the string entered is not a valid e-mail address, you will get the error message pictured.

    The reason is that a single-click set primary contact button requires a single result from the search, the only parameter that is definitely unique for Process Manager user is the primary e-mail address.

    If you want to search for a user based on its name you should use the 'Select User' button (magnifying glass icon) and the dialog window that opens.



  • 8.  RE: The specified Primary Contact does not exist in the Portal.

    Posted Sep 28, 2011 12:53 PM

    Is there a way to get around always having to use full e-mail addresses?



  • 9.  RE: The specified Primary Contact does not exist in the Portal.

    Posted Sep 30, 2011 07:10 PM

    I tried what you posted earlier on my test server but I must be doing something wrong. 



  • 10.  RE: The specified Primary Contact does not exist in the Portal.

    Broadcom Employee
    Posted Oct 01, 2011 03:38 AM

    Sorry, I obviously didn't manage to explain everything as well as I had hoped.

    The 'Text Equals Rule' should go next to the original 'Text Equals Rule (8.56)' (a little up and a bit to the right) like this:



  • 11.  RE: The specified Primary Contact does not exist in the Portal.

    Posted Oct 03, 2011 01:45 PM

    Thank you for the clarification. It looks like it is working. You are awesome.

    Thank you,

    Jen



  • 12.  RE: The specified Primary Contact does not exist in the Portal.

    Broadcom Employee
    Posted Oct 04, 2011 02:09 AM

    What does the checking, is 'Check for User' model. Specifically:
    - 'SearchUser (8.52)' component find users that have PrimaryEmail matching the string in the field and creates an array of such users
    - For Each loop after it loops through the array elements and verifies if the contents of that field match user's primary e-mail address - if it does, this one is going to get used, it goes out of the loop and the flow will continue.

    With Workflow, there is always a way around. In this case, it depends on what exactly do you need the end result to be.

    Most ServiceDesk users are using AD users, so the only other parameter of user I would use for the same purpose is AD login name. Steps to implement that idea are below. I did a little test and it seems to work just fine, except the first search was slightly longer in my test box. As always - don't implement that to your production ServiceDesk before thorough testing in test environment. This also falls clearly under the customization/not supported category :)

    Steps are based on 7.1 SP1 version of the webform, I don't expect the flow to be much different in earlier versions but I don't have test boxes for earlier versions right now to verify that.

    SD.Feeder.TechnicianIncidentForms > Check For User model:

    1. Add 'LoadByADLoginName' component on the 'exists' path of 'Is there a primary contact? (8.43)' component:
     Inputs: AdLoginName: Dynamic Value: YOURADNAME\[PrimaryContactDisplayName] (replace YOURADNAME with your domain name)
     Outputs: ADUserEmail

    2. Copy the 'SearchUser (8.52)' component and connect its outputs in the same place. Connect the 'LoadByADLoginName' output to the copied 'SearchUser' component

    3. Modify the copied 'SearchUser' component:
     Inputs: Email: Process Variable: ADUserEmail.PrimaryEmail

    4. Add 'Exception Trigger By Component' component:
     Trigger: Component: LoadByADLoginName

    5. Connect the 'Exception Trigger By Component' output to the original 'SearchUser (8.52)' component

    6. Copy the 'Text Equals Rule (8.56)' component and place the copy on the 'not equals' path of the original 'Text Equals Rule (8.56)' (a little up and a bit to the right from the changes made so far) and connect the outputs to the same place

    7. Modify the copied 'Text Equals Rule' component:
     Compare Variable: Process Variable: ADUserEmail.EmailAddress

    What I was trying to achieve with this, is to disrupt the original flow as little as possible. If finding user using AD login name fails, it'll fall back to the default flow with no ill effects (besides being a bit slower).