Classes Best Practices

Keep the following set of best practice recommendations in mind when creating classes:

• Copy Existing Classes to Create New Classes - If you have a class with a large number of reasons for events, and you need to create a class that is similar, copy a class and modify its reason lists rather than creating new reasons manually.
• Use the Same Reason Codes for Event Reasons Across Classes - For reporting purposes, define a set of reasons for events that may occur in projects that use models based on each class, and ensure reasons for similar events are the same across classes. For example, ensure the event reason code for the gate decision to kill a project is the same for all classes. If the reason codes are different across classes, you also need to create separate gate decision reports for each class.
• Create Unique Event Reason Codes without Reusing Deleted Codes - If you delete a reason that has not been selected in a project, the reason is deleted, and you can reuse its code. However, if you delete a reason that has been associated with an event in a project, the code is removed as an option from future projects, but remains assigned to events in existing projects for reporting purposes. If you re-use the deleted code, Accolade associates events previously linked to the deleted reason code with the new reason code. For this reason, Sopheon recommends using only unique codes and to avoid re-using deleted codes.
• Manage Classes for Accolade Innovation Planning Projects Appropriately - Accolade creates classes and associated models for planning projects as Planners create element types for planning and roadmapping. Changes to the class, such as changing the name or deleting the class, are reflected in the element type. Ensure that users with the Planner user role that are allowed to create element types and Process Designers within your organization understand that the changes to a class also change the element type.

Modifying Existing Classes

Consider how modifying an existing class changes projects and models based on that class.

Changes made to the following class details are reflected in models using the class and in current and future projects that use those models. All class changes apply to projects created after the class changes are saved.

• Display name
• System name
• Description
• Email notifications
• Project included on All My Work page
• Assignments included on All My Work page
• Include in Save to Accolade from Microsoft 365 applications.
• Changing Gate Line-up setting or the Reporting setting a default selection to an 'always' selection. Note that changing these settings enables the field in open projects, but the setting is not automatically changed.
• Changing the Reporting flag from a default selection to an 'always' selection
• Class icon selection
• Class-specific terminology changes
• Adding, deleting, or modifying event reason lists change the lists in current and future projects.