Jump to content

Victor

Administrators
 View Profile  See their activity

  • Posts

    5,696

  • Joined

  • Last visited

  • Days Won

    169

 Content Type 

Posts posted by Victor

    I can't get a new inbound routing rule to work on any criteria

    in Service Manager

    Posted

    @Berto2002 for routing rules there are 2 FAQs or guidance sheets as you call them:

    Routing rules do not process emails :: This is for scenarios where the routing rules simply does not process the email. The email lands in Inbox. This focuses on the potential issues with building rule expressions. 

    Routing rules do not raise requests from emails or apply emails to requests :: This is for scenarios where routing rule do process the email but fail to preform the designated action. The email lands in the designated folder for failures on the rule that processed the email.

    Both FAQs are listed in this sub-section of Service Manager area: https://community.hornbill.com/forum/147-faqs-common-issues-tips-tricks/

     

    • Like 1

    Suspended users due to incorrect userid and/or password

    in Service Manager

    Posted

    @Damian Roberts if the user enters an incorrect password a number of times specified in the security.user.lockout.failedLoginAttempts.threshold system setting their account is suspended (locked) for the duration specified in the security.user.lockout.duration (minutes) system setting. If the security.user.lockout.type is set to "permanent" the account/user is suspended indefinitely and must be actioned manually if it needs to be re-activated.

    Set up workflows for parent and linked requests

    in Service Manager

    Posted

    @Berto2002 indeed, it was advised before, as a possibility:

    On 8/11/2022 at 8:58 AM, Victor said:

    1. Have the main workflow in a Suspend Wait For Update - it will resume when an update is made on main request

    2. From the linked request, when resolved, push an update for a custom field of the main request

    3. From the linked request, when resolved, push an update on the main request, e.g. "Linked request 1 was resolved" or anything really, it just needs to be an update

    4. Have the main workflow refresh request details and check the value for the custom field

    At this point 2 - 4 will be looping and 2 will be updating a different custom field for each linked request and step 4 would be configured to check values for all these custom fields. If not all values are set, loop back to Suspend Wait For Update. When all values are set, meaning all linked request resolved and updated their correspondent custom field in main request, continue the main workflow.

    Just an idea, might not be the best, and it would more or less work for a fixed number of linked requests. It also needs available custom fields in main request. One could possibly explore the option to update one custom field only by adding content to this field each time a linked request is resolved then perhaps check for this value in the main request, e.g. how many characters or similar are in the string...

    However your solution is a bit less efficient, you don't need the 2-hour (or any delay), which means you create and trigger unnecessary events. With the above, you can have the main workflow resume only and when each linked request has been completed.

    Updating a Custom Field with the value of a Capture Task Field

    in Service Manager

    Posted

    Assuming functions.getTaskAnswers("task-8e8b6c91").field_1 has a value then you need a Get Request Details before outputting to timeline to refresh the workflow context data (variable values) after the custom field update. Mind you, the workflow is not using the data directly from the database it has it's own "cache" system (so to speak) which needs to be refreshed (e.g. with a Get Request Details) if the underlying data is changed (e.g. a custom field on a request is updated)

    • Like 1

    Questions behind email routing and auto update

    in Service Manager

    Posted

    10 minutes ago, JonathanMurphy said:

    REGEX_MATCH(subject LIKE '%Mimecast Request Form%','.*[a-zA-Z]{2}[0-9]{8}.*')

    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

    Reopened ticket is immediately closed.

    in Service Manager

    Posted

    @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...

     

    Microsoft Office365 IMAP\POP3

    in Service Manager

    Posted

    22 hours ago, lee mcdermott said:

    The only issue i see how ever we do it, if I am logged out of my o365 account I will need to know the password for what ever account we want to use? is that right?

    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.

    22 hours ago, lee mcdermott said:

    As as I say as I was reading various pages with links to other pages I was getting confused as to exactly what i needed to change, so maybe this bit isn't needed as it is already setup for us using o365

    Depends if the domain is set to use classic authentication or oAuth ... if oAuth, the set up steps are same as for inbound.

    • Like 1

    Microsoft Office365 IMAP\POP3

    in Service Manager

    Posted

    @lee mcdermott

    19 hours ago, lee mcdermott said:

    1. create a keysafe and then click connect. As below do I just use my own O365 account to accept permissions? Will this cause an issue at some point down the line? Or do I need to get a System admin for O365 account to do this permissions step or do I use the email account configured on the shared mailbox?

    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.

    20 hours ago, lee mcdermott said:

    Go into Shared Mailboxes area and change the Authentication Method to use OAUTH rather than classic? It then appears I need to provide a username and password of the account used to grant permissions from earlier

    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.

    20 hours ago, lee mcdermott said:

    Change our 2nd mailbox (also using O365) from classic to OAUTH - I assume using the same credentials as above?

    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.

    20 hours ago, lee mcdermott said:

    The email domain is already setup and working and doesn't mention authentication methods so I am assuming this doesn't need changed?

    Not sure what you mean by "email domain is already set up", can you detail on this please?

×
×
  • Create New...