I have created an extra site for the helpdesk widget.
It is one page, with the widget and some explanation.
I created a group ‘App-Assist’ (Azure AD Security Group, source; cloud)
This group is member of the ‘Visitors’ group of the widget site
External users (Azure AD Guests) can be member of the group ‘App-Assist’ and access the widget-site in order to create tickets.
This group, nor the external users, have a role or membership in the main helpdesk site.
When they create a ticket their contact information is recorded as follows:
Contact:
This is not really workable.
As you can see, the user has enough details in his profile to create a ‘good’ contact:
When the same user sends an email that is converted to a ticket, the information is recorded like this:
The two are not matched or combined.
We need a way for users to create tickets by sending an email to the helpdesk mailbox and / or use the widget and see both kinds of tickets in the widget.
[Opinion] The contacts list is the main 'user source' and that is not what I expected from an Office 365 / Sharepoint product. I expected that the product would use the users, departments and groups information available to sharepoint / Office 365. This is not the case, users have to be added manually / scripted to the contacts list, duplicates are created when users send mail and situations like above occur. The above scenario, where guest users (in this case tenants in our building) have access to parts of our Sharepoint environment and create and follow tickets is a vital use case for us which at the moment is not working as expected. [/opinion]
[EDIT] In order to work around this, in need some clear information on what the most important fields of the contacts list mean and how (on which field) an incoming email is matched to an existing contact. maybe I can then create a meaningful contact in the Flow that invites the user. Meaningful in the way that incoming mails are matched and tickets created with the widget also.[/EDIT]
Regarding the problem. Could you specify your SharePoint domain (send it as a private message to me) and check a SharePoint user profile for the same user as on your screenshots. Particularly, I am interested in the "Name" and "Work email" fields.
Regarding the logic of contacts creation, we don't need the "Agents" role in this case so I just leave it aside. There left two types of contacts (items in the "Contacts" list): end-users and members. End-user is created when HelpDesk receives a message from an external e-mail address. Member is an item which is bound with a SharePoint user profile (not Active Directory one as on your screenshot). There are three cases when it's created:
a user logins to a HelpDesk site;
a user logins to a HelpDesk widget;
a user sends a message to HelpDesk using the address specified in his SharePoint user profiles.
So, if there is a SharePoint user profile (even not registered in the contacts list) with an e-mail address from which HelpDesk receives a message, HelpDesk whether creates a member contact (if there is no such one bound with the current SP user profile) or do nothing. So there can't be duplicate contacts. But if a contact was created as an end-user first and only then he was added to your tenant as an external user (i.e. there appeared an SP user profile) then it will be duplicated as a member.
But in any case, a member contact should take name from an accordant SP user profile. On the screenshot above you can see contacts that were created when users login to HelpDesk widget. Their names are set properly.
The key fields for creation a contact item are full name, role, e-mail (if it's an end-user) or SharePoint user (if it's an agent or member).
I have just tested the complete solution I had in mind and I am very glad to report it now works as expected!
The external user is invited and through microsoft flow an organization is created for him and a contact with name, email, organization and phone number. Now when that user mails to the helpdesk or uses the widget, the tickets are nicely matched to his contact and he can see all in the widget.
Great! (-:
One more question: I have customized the widget 'new' form (to include categories), will this be reset when I upgrade helpdesk to the latest, modern ui, version?
No, the widget forms will not be reset since HelpDesk contains only links to their IDs. The forms are stored in your Plumsail account and will be in safe even if you remove your HelpDesk instance.
I have upgraded our installation to the latest version and modern UI without problems.
There is one thing however...
We intend to use helpdesk with other agent groups than our own (IT) deparment and I used a 'trick' to hide certain navigation tiles (like 'Settings'!) from other users (agents) by removing them from the corresponding items in the 'Navigation'-list. This worked fine.
But now we have modern navigation links on the left of the page and everybody can see all links and even edit or remove them
I've looked into 'publishing features' to enable security on links or enable security trimming (= links which targets you can't access are not visible) but I'm afraid of the consequences, like breaking the application, when I enable publishing features or deny access to certain pages.
Any thougts or advice on how to make sure not all users can edit or navigate the links?
Prevent editing of the left navigation (quick launch).
For this purpose, grant a contribute permission level to the non-IT agents. If you need, you can copy it as a custom permission level and set your own preferences.
"Settings" are certain pages united by common tab navigation. The pages are stored in "HD" library. Other system files are stored there too (e.g. forms backups, scripts, localisation objects, etc.). You can just stop permission inheritance for that library and remove permissions for non-IT agents (for each separately of for their SharePoint group). In this case the "Settings" link will not be seen by the contributors on the left navigation even without publishing features activated on the site.
But when you removed permissions for the "HD" library, the contributors lost also access to the "Reports" pages. To restore it, just grant permissions on folders "Reports" and "Dashboard Designer".
