Victor

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

@Stefania Tarantino are these 44 requests for the same service?

@HGrigsby https://www.hornbill.com/support/

@will.good @samwoo although this seems like an obvious option and something that should be there, unfortunately this is not very straight forward. I won't bother you with the technicalities (they are quite a bit of these in this area even if this is not apparent). We were looking for some time to enable this option on the webform however we do not have a solution that we are happy with at this time.

@Damian Roberts so, this? https://www.powershellgallery.com/packages/HornbillAzureIntuneAssetImport/1.0.0/Content/HornbillAzureIntuneAssetImport.ps1

@Damian Roberts https://community.hornbill.com/forum/132-integration-connectors-api-webhooks/ What API is that, what payload, etc... If the asset sub-state can be set from the UI then there is an underlying API that will set this value in the DB. We just need to find the right API and payload.

@John C do you want to prevent requests raised from portal or user app too? If just portal then you can disable portal visibility for the service(s) or you can set the catalog items service desk only. Disabling user log in via SSO achieves the same but it is a bit extreme... it will prevent users from log in Hornbill altogether...

@Jeremy I have seen the same on some of views in my instance, I have asked development to look into this.

@QEHNick Because time spent in task is a task functionality which is a Core item. Timesheets are Timesheet Manager app items and they only exist when the TM app is installed in an instance. Tasks (and their time spent functionality) will exist with or without TM app. Time spent in task existed long before TM app was created. You don't integrate them, with TM App installed you would use the TM time spent functionality. Without TM app you use task time spent.

@Berto2002 here. You would look for the "owner" in h_rel_type.

@samwoo tagged it as an enhancement

@samwoo right, so that's fine, it is confusing if "Intelligent Capture" concept is used on human tasks, given that we have an "Intelligent Capture" engine that is designed and works completely different than tasks, even if in some part, for a user, they appear to be somewhat similar on tasks. But yes, what you outlined above is not currently possible.

@chriscorcoran what roles does this user have?