Victor

No, that would not work, what you would need above is REGEX_MATCH(subject, '.*[a-zA-Z]{2}[0-9]{8}.*') AND subject LIKE '%Mimecast Request Form%' Here is an FAQ describing how routing rules and their expression work and common causes for when they do not: Also, another useful resource might be the documentation for routing rules: https://wiki.hornbill.com/index.php?title=Email_Routing_Rules EDIT: For the REGEX_MATCH criterion above I would recommend this one: REGEX_MATCH(subject, '.*\b[a-zA-Z]{2}[0-9]{8}\b.*') This is different in the way that it matches a Hornbill request reference as a distinct word in email subject (so it has a space before and after), rather than possibly be a part of another (larger) reference of some other sort

@Nikolaj unfortunately I am unable to have a look at it but you can use the service provided by your Premier Success plan and raise a support request with us if you think there is something not working correctly with Hornbill.

@Nikolaj in first instance i would advise going through the below FAQ which details the possible scenarios where routing rules would not be working. I understand you said these were working until recently (before) but we would still need to validate the configuration

@Nikolaj can you detail the issue please?

@Mark (ESC) I can only assume the workflow is at some form of staged closure and at this specific point there is a looping sequence based on status. Whenever you reopen the request the sequence resumes but in the loops through a path that closes the request. It could be due to conditions in decision nodes, perhaps values used there are not the right ones... difficult to say without actually looking through an example (request and workflow) where this behavior happened...

Basically, yes.. so on Connect (on keysafe), if no MS account is logged in on that machine, then MS will prompt to sign in as a user... and whoever that user will be (like the account that is actually being used for the inbound email) will have to type in the password for the account. Depends if the domain is set to use classic authentication or oAuth ... if oAuth, the set up steps are same as for inbound.

@lee mcdermott Ok, so when using oAuth we need to connect via the keysafe. So one needs to be created. When using "Connect" on the keysafe, we are in fact creating a token, which will be used going forward for this particular connection. This token needs to be created in an MS user context with sufficient rights to the O365 email account (sufficient here means reading, sending, and such, basically the operations that need to be performed by that email account/mailbox). You can use your MS account for creating this context as long as your MS account has the relevant rights for the O365 email account. While an option, usually the MS account for this token is perhaps a different MS account (such as your Sys Admin one). So when using Connect on keysafe you are prompted to use an MS account. You need to consider here what MS account will be used for this keysafe to allow the necessary email operations on the O365 email account. Be mindful that if your user is already logged in your MS account the token can be generated in this user context (which might not be the user you need) so an idea would be to log off from your MS account prior to using the Connect option on keysafe. This way you can ensure you will be prompted for an MS account. Yes, you would switch to an oAuth connection, for O365 email there are specific options in this list that should be used rather than a generic oAuth connection type. You would then specify which keysafe is used here, you should not be prompted to type in a username and password, this is only for classic connections. Not quite. The second mailbox can use the same keysafe, which means in turn will use the same token, if the MS user context (for which this token was created) has sufficient rights to this other O365 email account. If a different MS user context is needed for this other mailbox, a new keysafe needs to be created, using same steps as above. Not sure what you mean by "email domain is already set up", can you detail on this please?

@Osman live.hornbill.com is not using Microsoft email service (it is in fact not Microsoft) so no, it is not affected.

Alpha-2 code (so the two letter one) https://wiki.hornbill.com/index.php?title=User_Import_TimeZone_Fields_Options

@Mark Green

I know the product is not very helpful here as it seems to have the same naming for internal and external groups, so let's call external groups "Organisations" and internal groups "Companies". So what you are looking for is roles/rights to allow a user (one of your analysts) to manage (other) user membership for Companies, right? If so there is no dedicated system role for this but I think a custom role can be created with the following rights: I think the "User" and "Group" rights are required, at least "Manage" ones... Create/Delete can be added if the user should also be allowed to perform these actions on users and groups/companies.

@Paul H api.xmlmc.queryExec.maxResultsAllowed

@Berto2002 not necessarily. The system is designed so such actions can be reversed. What the system needs to ensure is that this association for archived users is not taken into account in current functionality, which is not the case for admin::userGetGroupList

@Berto2002 there is no anomaly in the database here... the discrepancy comes from what data is retrieved from the database in the two scenarios: a) user record -> organisations for that user The API that retrieves the list of users (admin::userGetGroupList) will display all organisations that the user is associated with regardless of the user status (active, suspended, archived) b) organisation record -> users assigned to that organisation The API the retrieves the list of users (admin::groupGetUserList) will display all users that are not archived. Users that are archives are excluded from the list. When a user is archived the organisation association record is not removed but the system will ignore this association going forward. The argument here is that admin::userGetGroupList should, potentially, not be run or ignore the association (so no data is returned, no organisations are displayed for the user) if the user is an archived user.

@Berto2002 Service Desk Admin is a Service Manager app role, thus it will not be found in Platform Configuration section in admin, but in Service Manager section:

@Berto2002 not a very helpful message there... these are direct outbound emails, there is no practical way to make use of the message ID anywhere in the UI to locate this message and review the delivery logs... something we would need to look into. Meanwhile, if needed, the delivery logs for this type of emails are stored in h_msg_direct_delivery_log table. If you filter on message ID (which in this occasion is 19530) you would get details of the delivery and if it failed, why it failed.

@Berto2002 you can make use of {{Customer Coworker.H_home_organization}} but that means a) user needs to have a Home Organisation set (which I would assume it does) and b) this actually gives you the org ID, not the name so it might not be what you are after in an email... If we need the name in the email this becomes a bit more convoluted, won't be that straight forward... 1. Get User Details (we need the Home Org from this one) 2. Get Organisation Details (we need the Name from this one) 3. Store the "Name" value somewhere on the request, most likely a custom field 4. Use the custom field variable in the email template to output the company name

@Berto2002 ok so, basically this statement is incorrect. {{.H_company_name}} is an email template variable and only used in email templates. In workflows you have workflow variables which are different than email template variables. The value for {{.H_company_name}} variable in an email template is retrieved from h_itsm_requests.h_company_name. If this has no value in the database for the respective record, the email will display {{.H_company_name}} (this is the default behaviour which can be changed by formatting the variable in email template configuration). "Get Request Information -> Customer Details" node will set the value for the "Company" parameter from h_sys_groups.h_name based on h_sys_account_groups.h_group_id for the respective user. As you can probably imagine, "h_itsm_requests.h_company_name" and "h_sys_groups.h_name based on h_sys_account_groups.h_group_id for the respective user" will not always be the same. I believe in your test h_itsm_requests.h_company_name is empty (no value) which means the request is associated with a customer but not a company while "h_sys_groups.h_name based on h_sys_account_groups.h_group_id for the respective user" does have a value given the user is associated with one (or more) organisations.

@Berto2002 and the "Get Customer Company" node?

@Berto2002 can you detail the "Get Customer Company" node and the "Yes" expression please?

@Chloe Carson the error you see there is because https://api.hornbill.com/admin/?op=contactSetAuthentication API fails to execute for the reason mentioned in the error, which is the value for <authCredential> param did not meet the required input pattern constraints. This is a "passwordType" param and it needs to comply with the patterns documented here: https://api.hornbill.com/_types/passwordType. Whatever value ends up in the <authCredential> param, it does not comply with this.

@Stefania Tarantino ah, so those requests are not actually assigned (yet)... right...well, that would explain it then since no action (but update) is possible on an unassigned request...

@Stefania Tarantino I'll ask my colleague (for who you have an active support request) to look at roles config for your users and we'll advise based on what we find...

Perhaps try and select a few at a time and see the options presented in the multi action... I think there is one (or more) that cannot be cancelled thus the option in not presented when selecting all 44... Also, does this admin account have the necessary roles/rights to cancel requests?

@Stefania Tarantino then you should be able to cancel these...