The main screen showing the workflow component of the application. Currently set to show all users, non-power users would be locked in to only see their tasks. From there, they can perform necessary actions and click “Step Complete” or “Roll Back”. This passes the task onto the next or prior user as defined in the workflow template.

This screen shows all tasks assigned to a user rather than the current task waiting to be performed.

These departments were functioning independently from one anther, communicating with via a costly and timely paper trail. The goal of the WCEAS application is to ease communication across departments by eliminating the paper trail and moving to an all-electronic form of communication.

A request is the term we use to encompass all three modules and the workflow component together. When a request comes in, it is entered into the system, assigned one of the available workflows, and the steps to complete that request are then entered into the system and assigned to the user who is to complete that task. A request holds the necessary resolution(s), contract(s), bid(s), document(s), tasks(s) all under one container, so all the departments can see the necessary documentation from the other departments. Extensive role-based security is in place so that each department can only change its own items. However, they can view the items they need the other departments to complete.

WCEAS action begins when a department submits a Resolution Request to be entered into the system by a Legislative Office Specialist. The specialist chooses a workflow assigning the appropriate tasks to the people involved in the process across the three departments. At each step of the workflow, a value in the form of data is added to the database or documents attached for the next department to review. Hundreds of requests can occur simultaneously. Users can track the progress of each request as well as the database records from all the departments. Records may include scanned or attached copies of actual supporting documents that lead to the final resolution, contract or awarded bid.

The Add Request Screen showing the Workflow Selection and the Assignment of the People to Substitute for each Role in the steps.

Tasks or steps are added under a workflow to show the steps needed to complete that task. Each step is assigned to a Role. When the request is generated, the members of that role are presented in a dropdown menu and the person to complete that step will be substituted and that step will show in their “My Tasks” when it becomes the active step of that task.

The Show Request Screen with the Tasks Tab selected shows that the workflow defined in the Workflow Header was imported into these steps when the request was added and the appropriate workflow was selected. From there the user can see the date completed and completed by notifications as well as comments for each step in the request tasks.

The Show BOS Products Table Page with no filter shows a history of 14,729 records that have been imported into the system from a legacy system. It contains a complete history of that Department’s doings for the past 20 years.

The Show Page for a particular Contract with child tables for Insurances and Expiration Dates, Documents, and a Comment table to record a history of all dealings with this contract.

There are 241 ASPX Web pages in the WCEAS application. We expect 25 to 30 daily users during the first phase of development. In phase two, we will allow all 800+ county employees to search.

Any user can access the Documents tab and see everything associated with that request.

The Show Request Screen has the Request Information, as well as child tabs where the request is linked to a Bid, Contract, BOS-Resolution, the task tab, the recipients tab to show who received notification of the request, and any uploaded documents.

The Edit Board Meetings Screen with a button to upload the Audio File. This is handled differently from the documents due to the large size of the audio files.

We used the Telerik RadUpload control which displays a nice progress bar during large file uploads.

A screen shot of the Telerik RadUpload Control while uploading a 105.49 MB file.

The Contract Module Show Table page with many filters.

The Bid/Purchasing Module with filters for Department, Status, and various dates associated with the bid.

The project could have been done without using Iron Speed Designer. However, it would have been a multi-developer project with each developer taking on one of the four modules of Board of Supervisors, County Attorney, Purchasing, and the Workflow Module. That process would probably have taken three developers six months to more than a year to implement.

This means that, given Warren County’s budget and personnel level, the project would not have been feasible. We only have two developers on staff and needed to be able to roll out many applications to the large number of users we support.

A Show Page for a particular bid with the child tables showing the vendors that were allowed to submit bids, any documents submitted and/or the official bid that was awarded, as well as a section for secured documents that only members of the Purchasing Role can see as it pertains to just their department. The Bid Documents are uploaded to the database and are accessible by any other user of the system with Read Privileges. This eliminates a call to the Purchasing Department to find the information and/or documents on a bid and print/copy/fax them over.

Jeremy has been programming for more than 10 years. He has experience in Iron Speed Designer ASP.Net Development, Delphi, Visual RPG, FoxPro, Microsoft SQL Server, and Microsoft ASP.NET, as well as Telerik ASP.Net Rad Controls. He is willing to work as a consultant and also offers training services.

Jeremy Scrime is currently a Senior Programmer/Analyst at Warren County in Lake George, New York. He has been using Iron Speed Designer as his sole means of application development for the past two years.