Can you provide an example customer/site so I can try to see if this is possible to configure in Customizer as mandatory but no default value?  I am thinking or wondering if other settings such as company, contract, etc. are involved in selecting an automatic priority level.

First glance, it looks like the priority is coming from the company/site definition or if a contract is involved from this point.  There does not seem to be an option to NOT have priority for either of these two entities.  If you try to remove it, it repopulates with the current value.

Based on this, I think you are looking at either a customization to not populate priority by default (which is not standard) or perhaps a process flow can be created to update the field to null when the document is created after the Save & Continue (can’t do this until saved as it i not in the database).

Thus I think a change request customization may be the best solution if you are trying to force it as blank and mandatory on the new screens.

The problem is that priority is necessary, especially to drive SLA’s thus there has to be one.  The system is designed to populated default priorities with a precedence based on for example, contract first, site/customer second, general setup last so that there would always be a priority.  The system is designed to streamline data entry as much as possible once selections are made and this is not an option to have a blank priority by default.

What you need is something to recognize the state of the field has not changed when they try to save the document to the database that you want to alert them they must select a priority but one is already populated.

My recommendation is to discuss this with your IFS project consultant for their suggestions.

The Priority is set from the following hierarchy: Contract > Item > Contact > Site > Customer > Product.  If the priority is not found on any of those records, it is set by the Default Priority workflow setting in the Miscellaneous I module.  The priority cannot be cleared as Phil mentioned and would require some kind of customization.

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” ?

This group is also monitored by program managers and R&D.  I will send the request to them as a separate channel but honestly, I don’t think it will be allowed to have a blank string as a priority in standard even though you will be forcing the user to submit it as mandatory.

As for the purpose of the heirachy not allowing a blank value intially, it does not invalidate the reason behind having this construction.  The purpose is that all of the entities mentioned might have a priority but may require a specific priority at the smallest level.  For example, you may have as a default priority 3 for the Customer but you agree a specific contract where this might be priority 4 or or priority 2.  The contract takes precedence as it is the smallest granularity in the heirarchy.

Contracts may have multiple items having different priority levels but needs to manage the priority on a contract level and not the default level of the item or the customer.  This is the purpose of maintaining a heirarchy.

What you are asking is to break the ease of use design to always populate the proper priority automatically.  You don’t want to populate it at all by default but still have a value mandatory.

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 ?

I have already sent the request and when I receive an answer, I will inform you.

The only other request I am aware of is the one Gijs raised regarding the Organization Tree being limited to 100 nodes.  This was already responded to in that topic with the response received from R&D.

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

Ok, I will ask that one as well and let you know.

Hi Piet,

As we discussed, this is also not something that will be implemented as new functionality in Alliance standard.  It will have to be managed as a change request for your code implementation if you wish to pursue this RFE.