I frequently run into the problem of "lifecycle management" for various entities.
In short, when some "thing" is created in our system e.g. an "order", "user" etc... there is a semi-automated song and dance commenced between customer service, customers, and community members, over the course of days or weeks...
For example:
- Order lifecycle: New, Awaiting Shipment, Pending cancellation, Awaiting Review, Disputed, etc... The problem isn't defining the states, but rather defining who could make a transition and when.
- Listing lifecycle management: Pending Review, Closed, Sold, Banned, Open, etc... Once again the complexity arises when we try to define which transition is allowed by which user, and at what point.
- Community membership management: Awaiting confirmation, Active, Probation, Banned
My idea was to create a low-code platform where you can easily design and deploy state machines. The goal would be that once you define the entity lifecycle (the state machine), You could just send us an API request anytime a new entity was created in your system, and we would handle involving the key people needed at the right times, sending notifications, status updates, etc...
An example: https://imgur.com/a/mr5Pdss
This represents an order's lifecycle. Once deployed, you could send an "order" to this service to kickoff execution:
1) Purchased - sends a notification to customer service that a new order was purchased. The "Customer Service" role (“C”), can take the action "confirm availability", which when taken, transitions the entity into state "Confirming Availability".
2) Confirm availability - Whoever is assigned to the "warehouse" role (“W”) would receive a notification that the order is in this state, and once they confirmed availability, could either take the action "available" or "unavailable" transiting to the order to the appropriate state.
etc…
Does any of this make sense, or have I gone off the deep end?
In short, when some "thing" is created in our system e.g. an "order", "user" etc... there is a semi-automated song and dance commenced between customer service, customers, and community members, over the course of days or weeks...
For example:
- Order lifecycle: New, Awaiting Shipment, Pending cancellation, Awaiting Review, Disputed, etc... The problem isn't defining the states, but rather defining who could make a transition and when.
- Listing lifecycle management: Pending Review, Closed, Sold, Banned, Open, etc... Once again the complexity arises when we try to define which transition is allowed by which user, and at what point.
- Community membership management: Awaiting confirmation, Active, Probation, Banned
My idea was to create a low-code platform where you can easily design and deploy state machines. The goal would be that once you define the entity lifecycle (the state machine), You could just send us an API request anytime a new entity was created in your system, and we would handle involving the key people needed at the right times, sending notifications, status updates, etc...
An example: https://imgur.com/a/mr5Pdss
This represents an order's lifecycle. Once deployed, you could send an "order" to this service to kickoff execution:
1) Purchased - sends a notification to customer service that a new order was purchased. The "Customer Service" role (“C”), can take the action "confirm availability", which when taken, transitions the entity into state "Confirming Availability".
2) Confirm availability - Whoever is assigned to the "warehouse" role (“W”) would receive a notification that the order is in this state, and once they confirmed availability, could either take the action "available" or "unavailable" transiting to the order to the appropriate state.
etc…
Does any of this make sense, or have I gone off the deep end?