Idea ID: 2869871

MF connect default user when user is missing in one of the endpoints

Status : Under Consideration

We have the notion of a "default fallback user" on our roadmap for the next main version (4.5, likely in December) - but only as a SHOULD-HAVE.

While the notion of this functionality is very clear, the technical implementation poses challenges in effort (very large) and function (100% applicability likely not possible).

Just to name a few reasons (there are several more):

  • Some products do not provide clear error messages like ("this user is not valid") in all cases when supplying a not-existing/non-valid user value.
    Instead, in some cases, one might just get a generic server error 500 and no context.
    I.e.: It is then unclear what triggered the error - the user value? another field value? a workflow violation? the server itself hiccuping? etc.
  • Checking the new user value against a list of allowed users is either not feasible (performance) or the list is simply impossible to retrieve for many products (For example, Jira has strict data privacy rules that mostly prevent the return of any list of users).

We might "effort-box" this item for the 4.5 release. I.e. only provide this for some products and not for all edge-cases of these products. But this has not been decided yet (and will be some time)!

Which makes your specific scenario problematic!
-> Most customers ask for the "fallback user" feature for ALM/QC and Octane - but not for 3rd party products like Jira, ADO or ServiceNow - typically all users are in the 3rd party products and the account in ALM/QC or Octane are limited...


See status update history
2 months ago

Hi,

Use Case we have: external users (=customers) can be added to Octane, but are not allowed to be added to Jira due to some internal regulations. In synchronization links fields Owner and Author  are synchronized with Jira fields Assignee and Reporter.  When  external users create entities in Octane, synchronization starts failing, since users are missing from Jira side. We cannot create Jira accounts for them (even some technichal accounts for synchronization purpose).

How we see the solution: it would keep synchronization working, if we could add in MF connect link condition that "when the user is missing in one of the endpoins (in our case it's Jira), then some default constant value should be used (=technical user).

Could you please investigate if it's possible to add such functionality in MF Connect?

Thank you!

Best regards, Nataliia Positko

Labels:

AlreadyInOctane
Configuration
Sync Behavior
  • We have the notion of a "default fallback user" on our roadmap for the next main version (4.5, likely in December) - but only as a SHOULD-HAVE.

    While the notion of this functionality is very clear, the technical implementation poses challenges in effort (very large) and function (100% applicability likely not possible).

    Just to name a few reasons (there are several more):

    • Some products do not provide clear error messages like ("this user is not valid") in all cases when supplying a not-existing/non-valid user value.
      Instead, in some cases, one might just get a generic server error 500 and no context.
      I.e.: It is then unclear what triggered the error - the user value? another field value? a workflow violation? the server itself hiccuping? etc.
    • Checking the new user value against a list of allowed users is either not feasible (performance) or the list is simply impossible to retrieve for many products (For example, Jira has strict data privacy rules that mostly prevent the return of any list of users).

    We might "effort-box" this item for the 4.5 release. I.e. only provide this for some products and not for all edge-cases of these products. But this has not been decided yet (and will be some time)!

    Which makes your specific scenario problematic for 4.5!
    -> Most customers ask for the "fallback user" feature for ALM/QC and Octane - but not for 3rd party products like Jira, ADO or ServiceNow - typically all users are in the 3rd party products and the account in ALM/QC or Octane are limited...