Bad Practice in using Polarion
Here we give you some examples what you shall not do when using Polarion at your company.
Im Gegensatz zu best practice stehen Beispiele, die als worst practice bezeichnet werden müssen, weil sie ineffizient und unproduktiv waren und schlimmstenfalls zum Scheitern einer Aufgabe geführt haben. Darin drückt sich eine A-posteriori-Perspektive aus, d. h. es wurden identifizierbare Fehler begangen.
Monster Workflow
 Do not create workflows which  allow transitions from any status to any status. This kills the whole idea of workflow as predefined  sequence  of steps to control "work flow".
It makes sequence  of transitions unpredictable for  managers and  not undestandable for end users. They see "unlimited possibilities" of  transitions, but they  do  not  see the "workflow".
	
Everyone can do Anything (Access Rights Freedom - leads to Anarchy)
 Giving too much freedom (access  rights)  to  the users will lead to a  Mess.
 Polarion has an advanced and easy to handle Access &  Permissions Management. It is  always good practice to restrict user access  rights. Not everyone shall  be  able  to  do some  actions.
  
  
Too many special Permission rules can overload Polarion
 Having too many special rules (exceptions) for "permissions" to work items, documents, spaces, etc. - can overload Polarion.
All these rules about access rights shall be evaluated before the data is displayed to the user. Polarion has to check first if the userreally has access rights
to see the data and to perform edit operations.
Especially this is important for Report Pages. If Polarion has to analyse hundreds or thousands or work item, and for each it needs to calculate
complex access rights - then teh system will considerably slow down.
SOLUTION: keep permissions simple. Do not over-complicate.