Victor

@Paul Alexander ... do you import the basic users from somewhere? How are the users created (e.g. the ones you mentioned to me for example) The issue occurs because the users have an invalid date format set against their profile. If you look at the user profile in admin tool you will see the data format field empty. But this is not actually empty, it displays as empty because it contains a value not recognised by Hornbill. You can see this if you look at the user record in the database: that date format is dd:mm:yyyy. Quick fix, ask the affected users to change their date format in their profile (or change it yourself in admin tool) and, if you import the users from somewhere else (like AD), make sure you populate a valid date format for the imported users (by valid format I mean a format accepted by Hornbill).

@Paul Alexander who are these users? (id's) ... you can send this info in a PM if you like for privacy reasons...

@Martyn Houghton hmm... maybe use a request custom field to store the task outcome and then use this custom field in the template?

@Martyn Houghton as far as I know the date/time values in email templates will have the format defined in system settings... Try and changed these settings and see if the template picks up the new format...

@Martyn Houghton we are working to have this functionality improved (i.e. higher degree of flexibility in configuring the timeline update for tasks).

@SJEaton yes, you can... The information you need is stored in h_sys_tasks table. You need to be aware that a request can have multiple tasks associated to it so remember this when building the JOIN and other filter criteria.

@Stephen Hutchinson @Martyn Houghton We have updated your instances to address this issue. The update includes a revised functionality around email to address the bare line feed rejection. When you have a chance please have a look and let us know if the issue still persists or not in your instances.

@Rohit Govind just an FYI, the issue was fixed in your instance and the permanent fix was also included in the latest SM build, now available for update in live instances.

@Stephen Hutchinson I'm afraid not. If they (our cloud team) were to replace the templates they will basically copy the files from our repository and deploy them in your instance. It will basically override all existing templates. However, I would advise to hold on for now on this. I just had a chat with our platform dev team and they seem to have something ready to fix this issue cater for this scenario early next week. So I think (fingers crossed), if all testing goes well on Monday, we can deploy a fix an update your instance on Tuesday ( @Martyn Houghton FYI).

@lee mcdermott

@lee mcdermott sorry, forgot to mention. Being a single line text field, it has a limit of 255 or 275 characters.

@lee mcdermott yes, the description of the request itself can hold more than 255... (up to 65535 or whatever the limit is for the TEXT type fields)

@lee mcdermott Something like this, yes. "h_custom_..." fields in requests table and field in questions, are two separate entities... The "Questions" section of a request is using the info stored in "h_itsm_questions" table. Here you can store more than 255 because for each question/answer you have a separate record. The mapping to custom fields in requests table, the fields you can add in the "Details" section of a request, will be done on "h_custom_..." fields in requests table. Here you have the 255 character limit. Because all data in custom fields will be stored in one record, teh record for the request. And you can't make these fields to hold large amount of text, the performance impact would be unbearable.. There is a change in the backlog to redesign this functionality to allow custom fields to hold more than current limit.

@lee mcdermott this ^

@Stephen Hutchinson I need to have a look at your current templates and see the difference... just a quick note, the "new" templates (templates created as new in your instance) will be removed if we deploy our default templates... Just a quick question, did you have a look if is possible to (temporarily) deactivate/disable the bare line feed rejection in your Office 365?

@SJEaton it can be any role, as long as it has this system right: So, you can create a custom role with just this right and associate the users who need it....

@lee mcdermott maybe split up the description in more than one field? I know, I'm not making this easy, just trying to see what would work...

@Stephen Hutchinson I suggest following this thread for updates on this: Yes, the should work. I can ask our cloud team to see if they can deploy the default email templates files in your instance.

@lee mcdermott if one fails, they all fail .. that's being "h_custom_..." fields. You can limit the number of characters in input using REGEX validation.... You could use these REGEX functions: ^(.|[\r\n]){0,255}$ or ^[\S\s]{0,255}$

@nasimg I hope it works, to be honest, I haven't tried it but my logic tells me it should... however, the voices in my head...sorry, my logic, proved to be not 100% right on some occasions so I am curious of the results

@lee mcdermott so, the reason why the custom fields failed to populate is because the number of characters for the information (text) in one of the fields (h_custom_e) was greater than the max. number of characters allowed for the field (255). Looking at both examples you mentioned, the "Description" information/question, in both scenarios, is over 300 characters... The only solution I can think of would be to limit the number of characters during input for "Description" to 255.... and perhaps any other text field where this might happen...

@lee mcdermott it is not the same issue, but behavior is the same... so the defect you mentioned is fixed... this one here is caused by something else... Now, I can see why the template did not populate the variables, the custom field values are simply empty in the database... so the issue (somehow) occurred during mapping process in ProCap... I'll keep looking...

@SJEaton it is Friday!! Yay! However, even if the ProCap was missing something it shouldn't really behave like this when teh ProCap runs... it should give back some sort of information that it can't progress... I'll run some tests and see if it needs mentioning to our dev team... (perhaps I a missing something that's why)

@nasimg not that I'm aware, I'm afraid... I did thought of the exact same thing yesterday that it might be a bit of a chore if an instance has a high number of services and/or teams... Would be worth suggesting as a future functionality... maybe a temp solution would be to create a "dummy" service and a "dummy" team... and in the filter criteria, instead of having service = a, service = b, etc... have service not equal "dummy" ... same logic for team...

@Paul Alexander in admin tool, in Roles view, you can filter them by application. Make a note of the "Service Manager" roles then have a look at which user have one or more of these roles...