It is not the strategy I personally would have chosen. I would have defined the 7 states, and defined the 4 attributes as properties of the application object. You then have to define business rules that apply to the application based on these attributes that may apply changes of state to the application.
The benefit of this approach is that additional business rules are implemented in code as additional business rules which is very maintainable.
In your design, you are encoding business rules into the state machine, which means that over time, as business rules are introduced the state machine grows and becomes completely unmaintainable.
As an example:
public decide_next_state(IApplication application, Dictionary<state, List<IBusinessRules>> rules)
// by default we remain in the current state.
next_state = application.current_state
foreach(state in rules.keys())
bool matched = true;
foreach(rule in rules[state])
// if this business rule blocks the transition, then it
// returns false.
if rule.apply(application) == false
matched = false;
if(matched == true)
next_state = state;
Now with this code, you would pass in the rules dictionary for the applications current state. The rules then define which state the current application is will transition to. However it can only make that transition if all the business rules for that transition allow it.
This is a very simple model, but it can be made much more complex if you need to.