Is it a good practice to burn business logic into Enums?

Let's have a simplified business logic like this:

public enum BusinessLogic {
   STAGE_ONE(true, false, false),
   STAGE_TWO(true, true, false),
   STAGE_THREE(false, false, true);

  private final Boolean canStartProcessing; 
  private final Boolean Boolean canDoStuff; 
  private final Boolean Boolean canFinish;

  private BusinessLogic(Boolean canStartProcessing, Boolean canDoStuff, Boolean canFinish){
     ... usual simple constructor
  }
  ... getters
}

And let's say it is mapped to my Business Object like this:

public class BusinessObject {
  ... constructors, fields, getters, setters, etc...

  private BusinessLogic logic

  @Enumerated(EnumType.STRING)
  @Column(name = "LOGIC")
  public BusinessLogic getLogic(){...usual getter...} 

  public BusinessLogic setLogic(){...usual setter...}
}

When the workflow arrives for example Stage two, the BusinessObject will be updated and setted to BusinessLogic.STAGE_TWO, therefore you can use functions like "start process" and "do stuff", before that you can't, when it reached stage three, you can't do anything just finish the process.

Does this kind of business logic structure has something to do against good practice?

I mean for example: maintainability, not fully represented in Database or anything else I didn't think of?