Skip to main content
The limit and incident statuses are determined by their workflows. When using a custom workflow, it’s likely that the status values will differ from those provided in the default limit workflows. We need to map these statuses to the actions that can be performed on the limit or incident so that Atoti Limits is able to function using any custom statuses. This mapping can be configured using two different methods:

​
Use configuration properties

The following properties can be defined in your application.yml file to map custom workflow statuses to limit actions. These properties are prefixed with limits.workflow.limit-workflow-action-statuses:
PropertyDescriptionDefault Values
inactiveIndicates the limit is no longer active, making it ineligible for consideration during the validation of new limits. Limit structures with only “inactive” limits will have their KPIs deleted.DELETED, EXPIRED
evaluableIndicates the limit is eligible for evaluation.APPROVED
kpi-visibleIndicates the limit is still relevant to be viewed in KPIs, even if it’s only for historical analysis and is no longer active.APPROVED, EXPIRED
pendingIndicates the limit was previously approved and is still active, but has been modified or requested for deletion and the modification/deletion has not yet taken effect.PENDING, EDIT, PENDING_DELETION

​
Use ILimitsStatusManager

The ILimitStatusManager API provides methods to check if a limit has a status that is eligible for certain actions. The default implementation of this interface is DefaultLimitsStatusManager, which checks the limit status against the configuration properties mentioned above. If you don’t wish to use the configuration properties or need more complex logic to determine the mapping, you can create a custom implementation of this interface and expose it as a Spring bean to override the default implementation. 
/**
 * <b>ILimitsStatusManager</b>
 *
 * <p>This interface contains methods to check if a limit is eligible for certain actions based on
 * its status. The value of the limit's status is determined by the workflow it is in, which may use
 * custom statuses different from the ones in the default limit workflows.
 *
 * @author ActiveViam
 */
public interface ILimitsStatusManager {

  /**
   * Checks if the limit is in an inactive state and should not be considered for things like
   * evaluation or when validating other limits.
   *
   * @param limit the limit to check
   * @return true if the limit can be created, false otherwise
   */
  boolean isLimitInactive(Limit limit);

  /**
   * Checks if the limit is in a state that allows it to be evaluated.
   *
   * @param limit the limit to check
   * @return true if the limit is eligible for evaluation, false otherwise
   */
  boolean isLimitEvaluable(Limit limit);

  /**
   * Checks if the limit is in a state that allows it to be viewed in a KPI.
   *
   * @param limit the limit to check
   * @return true if the limit is viewable in KPI, false otherwise
   */
  boolean isLimitKpiVisible(Limit limit);

  /**
   * Checks if the limit is in a pending state, meaning it was previously approved, but has since
   * been modified or deletion has been requested and is awaiting approval for the
   * modification/deletion to take effect.
   *
   * @param limit the limit to check
   * @return true if the limit is pending, false otherwise
   */
  boolean isLimitPending(Limit limit);
}