I had some issues today with the customizer and had to flushe all cache before Aste reacted normal again.I retried to Customize the Request Type field and Astea behaves correctly now ! It works in both modules Customer Support Order and Service Order where on NEW the default Request Type is filled in.
after editing the title on the open Service Info page, the customization I did on the fields in teh Service Info page did not work after a public publishing. Did not work for multiple users.I had to flush all cache after login via the web and then the customization worked OKI also noticed that now I could adapt the style of all fields in the title and could also publish that correctly.Indead about sorting the fields is in the drop-down list in the title editor, if adding a mandatory field with a condition, then you have all fields correctly ordered in a alphabetic order which make selecting much more easier.
Thanks for following up this request with R&D.The question on Organization Tree has been answerd, but still have the question on resolve codes open: select 1 Resolution Code
We only use a smal number of choices per code which are very generic.For analysis (report) the combination of the 3 codes with product and customer works fine for us. But most anoying for our users is that they have to click multiple times to select and if only 1 may be selected, a 1-click solution would be very practical, certainly on mobile where the user screen is very small.is this someting program managers and R&D would concider to be in the standard ?
Yes, that is my question, always have a blank priority by default when NEW order is selected, but as it is made mandatory, the user needs to select a priority before saving the new order.At the start of our migration project we evaluated the Incident Management module were you have to define impact and urgency to result in a priority but the conclusion was that Customer Support beter suited our needs.That is why the system cannot define the priority correctly and if the field is already populated, we do not force our users to select a correct priority based an a customer priority decission matrix (out of Astea)Is there a possibility to have insight in what request are reviewed by program managers and R&D and what is the outcome of the review ?
You stated the hierarchy and mentionned if in each item the priority is not found, then the default is taken. The problem is that you cannot leave the priority blank in any of those items, so what is the use of a hierarchy or a default priority ?We got already several answers on topics raised in this forum which only could be resolved by a customization by Astea. Today we have a lot of customizations in our actual version which results in problems for upgrading, so we decided to stick to the standard implimenting v15 which has possibilities to be customized by ourselves using Customizer en Process Flows. Is there somewhere a possibility that customer requests are revued by a “Change Board” ?
I customized the field to fill in the text SUPPORT which we would like to have as default request type on the NEW page. This still results in a blank field on the NEW page, no matter if I check or uncheck “Only When Empty”.I did the same customization on the Description field and there the text I entered is correctly shown as default.What goes wrong with the Request Type field ?
Are there more customers who have that requirement ?If so, is that an enhancement that IFS would consider to implement in the standard of a future release ? Maybe by making it configurable as multiple or singel selection in the Workflow settings.
This means that for Belgium/Dutch, Belgium/French and France/French their is actually no difference?Differences per country - like keyboard layout - set up on the mobile device are not influenced by this selection in the employee security?
I left only US and CA as an exception in both rules and had no further errors on importing site or contact.Will those settings in the configuration editor be overwritten when we install a HF or upgrade to a new version ?
Is there a standard to populate the state/provinces so the GIS validation doesn’t give an error at import or do I have to create the state retroactive each time an error occurs ?Or can the population of the state/province field be excludes during the GIS validation as it is a non mandatory field ?
The State\Province isnot defined in the import template for the site, the GIS address validation populates that field automatically during import.
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.