-
Suggestion
-
Resolution: Unresolved
-
1
-
Issue / Use Case
Customer has built an automation rule to handle the existing customer user base without an organisation set. When a customer (without an org) creates an issue it will then set an organisation for them, however this does not set the organisation in the customer's would commonly expect, this is due to the current search/match implementation.
Current behaviour (Summary)
- When Use Reporter's Email Domain is added to an action on Organizations in an Edit Issue action, a request is made to retrieve all JSM orgs.
- The system then compares the reporters email domain to the first user on the org that was returned via API.
- If they don't match, we keep looping over the orgs and comparing the user's domain to the first user of each org.
- When the first user on an org matches with the domain of the reporter then we assume that the user should belong to that org and we cache this info saying that Domain "XYZ" belongs to org "XYZ"
Improvement suggestions
- The search algorithm should make primary use of the Manage email domain parameter that can be set on an organisation (if available).
- The ordering that the organisations are evaluated in is important, if alphabetised customers would have more control over which organisation is evaluated for a match first.
- If an organisation is empty, it should still refer to the managed email domain value.
Basically this means that currently within automation the manage email domain feature for organisation is ignored, the function loops over the organisations (based on id) and matches the first organisation that has customers with matching domains. The outcome in my case (especially when a matching customer domain is a member of multiple organisations) can feel like a totally random choice.
To me, this sounds like a bug on the implementation of manage email domain feature where it didn't take in account the existing functionality to edit/set the organisation of a customer.