6 Replies Latest reply on Sep 15, 2020 2:52 PM by Nicolas Roome

    Customers Displayed in Assignee Picker Fields

    Bret Swart
      Share This:

      We have a couple of projects in jeopardy due to some issues in Footprints 20.18.03 and beyond.

       

      Our objective is to migrate two workspaces Into FP12 from our FP11 environment. 

       

      Issue #1 - We discovered the "default customer for email" role does not apply to a person who has an existing role elsewhere in FP12. For example, none of our Service Desk agents can be treated as a customer in the new HR workspace unless their account is changed to have the customer role in the new workspace. The same is true for the those new HR agents as they can no longer be treated as a customer when calling our Service Desk unless they have been added to the Service Desk workspace as a customer.

       

           The behavior: Emails will not be sent or received from the customer so they can no longer update or create tickets via email.

       

           The resolution per support: Make all agents a customer in the other needed workspaces. This brings me to next issue.

       

      Issue #2 - As a result of the resolution from issue #1, we discovered all customers can now be assigned to tickets in the assignee picker field. The customer names appear as if they are agents when you either type the name or use the pop-up window do pick the assignees. This means customers who don't even have access to a ticket, could be assigned to it.

       

      Support has informed me this is a defect (DRZNZ-5395). The defect was initially logged against version 20.18.02 and, from what I can find in the release information, has yet to be resolved in any current version of FP20.20.

       

      My question: Has anyone else figured out a workaround to keep customers from showing up as assignees ?

       

      Luckily, we discovered this in our test environment. Our projects are on hold until we can prevent this from happening.

        • 1. Re: Customers Displayed in Assignee Picker Fields
          Romuald Bois

          Hi,

           

          Not sure I'm getting all of the issue in #1.

          By design, in Footprints 12.XX - 20.XX, agents cannot be both customers and agents in the SAME workspace, that is simply impossible.

          Now, if you create a new workspace from scratch, this needs to be defined in each agent's profile with a role.

          This is exactly where you can decide if a user is actually going to be taken as an agent or as a customer, or any other role you like, in a particular workspace.

          Therefore, when an email is received from an email address, if the email address the email originates from is found to be an existing user's, then Footprints first tries to check if the role is an agent or a customer one, and then we create the ticket.

           

          If this doesn't work, then we have to inspect what is going on when the email is received by looking at the log closer.

           

          #2 i indeed an existing and ongoing defect. We are still working on a solution so far.

          • 2. Re: Customers Displayed in Assignee Picker Fields
            Nicolas Roome

            For issue #1, this is normal. A user who does not have a role in a container will not have access to that container. If someone was not a user before, just a contact, and now they are a user, they will need the appropriate roles in all containers they use.

             

            For issue #2, that defect is still open.

            1 of 1 people found this helpful
            • 3. Re: Customers Displayed in Assignee Picker Fields
              Bret Swart

              Allow me to clarify a bit on #1.

               

              If someone has an existing role anywhere else in Footprints, they cannot be a contact in this new workspace unless they have been assigned a role in that workspace. Incoming and outgoing email fails for these individuals. If I change their email address to something that isn't associated with anyone in Footprints, it falls back to the "default customer" role we have set up for all external contacts.

               

              So if the logic would be for Footprints to only check the container role where, if there were no existing container role then treat it as an external contact, all would be fine.

              • 4. Re: Customers Displayed in Assignee Picker Fields
                Nicolas Roome

                That is normal. They can still be a contact, but you're right that incoming email will fail. Outgoing email should still work fine since it is based on their email address and the Portal Guest role. But incoming email would fail since the way it works is that it attempts to match the incoming email address to the address of a user (either customer or agent). If it matches, then it follows the permission from that user. In your case, that user does not have role access to the container, so therefore they don't have permission to update. In the event there is no user, then FootPrints will default to the configured 'Default User' configured user's role permissions in Incoming Email (Workspace) for that particular workspace.

                 

                So yes, the moment you create someone as a user in FootPrints (either as a customer or an agent) you need to ensure that user has permissions to every container they would interact with. If you need to bulk update existing users, I can provide you a SQL query that can 'export' your users in an importable format. You'll then need to tweak it to include the new role(s) and ensure the file is split and separate import packages created for each of your System Roles that you use.

                • 5. Re: Customers Displayed in Assignee Picker Fields
                  Bret Swart

                  Thanks for the offer, Nicolas. We were provided the queries and had successfully tested adding AD groups  and using the LDAP import option for adjusting containers and roles. For future reference, in our tests outgoing email also failed.

                   

                  The second issue with the defect is where we are stuck. I'm not sure we can take the risk of having a customer assigned to a ticket in any of our workspaces. I've been our FP administrator for 16 years now and we could usually either find a work around or live with the issues in the past. I'm not sure we can do that in this case. I'm a bit surprised this issue was identified two years ago and has yet to be addressed.

                  • 6. Re: Customers Displayed in Assignee Picker Fields
                    Nicolas Roome

                    Yea defect discovery to resolution is a lot longer than I'd like. This particular defect I don't feel is a show stopper per se (although I'd agree it really doesn't look good on the vendor's part). The reason I say this is primarily for the reason that it only impacts agent users. Agents should always be trained to only assign tickets in the following:

                     

                    - To another team

                    - To another agent, only in circumstances when there has been a warm transfer (ie: talked to that agent in particular)

                     

                    Couple that with the fact that generally teams are fairly small and people know each other, the odds of an agent choosing a customer user are slim (IMO).

                     

                    In your case you need to weigh the pros/cons of the upgrade (but with 16 years experience you know this all too well!)

                     

                    And here you can also consider that round-robin is now a feature, so maybe that will 'workaround' this defect for you?