It has been 6 crazy months, but my team is finally getting notification that our maintenance solution is almost ready for production. In a nut shell, a Florida agency needed a maintenance solution to manage maintenance for dorm rooms internally and externally to its tenants. For example, if a tenant had a leaky faucet, he or she could punch out a maintenance request and it would get assigned and worked, with the tenant being able to verify the request's progress. The cool thing is that the dorms have visually impaired tenants so it was real important to make sure the interface was not only 508 compliant, but added custom functionality to make the UI even more user-friendly. Other than making sure that HTML was well formatted with metadata, we also used AJAX to take care if postbacks. One scenario called for building custom cascading dropdowns that were fed via SQLServer. In fact, the agency used this functionality as a standard for other applications.
In addition to being 508 compliant, the solution also called for the ability to manage a maintenance request. This is where WF was used to handle these long running processes. Here is the flow
- Maintenance request is created.
- Maintenance request is assigned.
- Maintenance work is completed.
- Maintenance work is approved.
After a request is created each of these states could only be changed based on the role of the user logged in. The roles were as followed...
- Requestor - Requests maintenance
- Supervisor - Assigns work and approves the work
- Staff - Completed the maintenance work provided within the request.
- Admin - God rights(could do most of the above)
However we also used policies for when a request could transition. For instance,
A role could not create and assign a request to themselves.
Work done by a supervisor or staff could only be approved via another supervisor or admin, however even an admin could not work and approve maintenance for a single request.
I could go on and on about the business rules of this solution and how WF simplified the requirement, however the important part is the role that WF played with helping us meet our deadlines through
- Simplicity of modeling the process.
- Flexibility as business rules changed.
The true art of WF being a framework can be observed by doing a project of this size, because you see where all the pieces fit. From changing the flow to changing the business rules via policies, everything is compartmentalized so you can specifically go to the modulated area to implement or manage change.
This project took a ton of my time and soul to architect and build, but don't they all? Especially when you build something that is used for such a tremendous cause. I will be speaking at VSLive next month, and some of my experience based on this project will be shared in my presentation and demos, so if you get a chance to attend my session, come up afterwards and let me know you read this post!