4 Replies Latest reply on Sep 20, 2010 11:48 PM by electric_soul

    Post: Workflow control, my approach

    electric_soul

      Title

      Post: Workflow control, my approach

      Post

      Hello everybody

      I'd like to develop a workflow control. I am tired of coding each possible way of what the next workflow-step might be.

      I thought I base the workflow on the records overall status code. A overall status code is nothing else then a combination of status fields. Each field holds a status, like "in process" or "open" or whatever.
      Depending on what the overall status is, I can choose, lets say from a dropdownfield, what the next possible action should be. An action will alter a status field and therefore the overall status leading to a new overall satus code. Each action is tied to a script.


      All of the overall status codes will be stored in a workflow table. The actions will get their own table, being connected to the workflow table.

      Finally, each time an action is executed a script or several will be started. After that I have a new overalle status and new possible actions that I can choose from.

      When it comes to define who is actually allowed to alter a record in a specify status, I thought I add a field to a table, called 'assigned_to' which holds an account name or privilegename. This one will be evaluated by a script and the record access control of the internal filemaker securty solution.


      Is this a good approach of controlling a workflow? How do you guys do it? How to control a workflow, without coding to much.

      Bye                           <!--POLLS--> <!--FILES--> <!--SIGNATURE-->

        • 1. Re: Post: Workflow control, my approach
          rjlevesque

          So by workflow you mean something like a small project manager type of system/solution?

          • 2. Re: Post: Workflow control, my approach
            electric_soul

            Well, here is an example.

            You open a complaint, because a customers called ....his product is defective or something. This is when the workflow starts. Now you pass this complaint through a couple of departments. You have to do some repairs , send loaners, do this an that. The whole process follows a process chain. But the chain has branches too.

            How do you control this process? how do you pass the complaint around? Depending on the current process step, different things have to be done, and different people have to get involved. how do you do this without scripting the hell out of filemaker?

            So a workflow, something like a roadmap, would be a good approach. Each station must be connected to actions which the user can choose from. The actions determine the next station on the roadmap.

            bye bye

            • 3. Re: Post: Workflow control, my approach
              philmodjunk

              Proper table/relationship design would be key here. You'll want not only to be able to easily "route" each such record the the right department and/or person, but I imagine you'll want a complete log of each phase of the process so that you can later review what happened so that you can analyze your process for possible improvements.

              I imagine you'd need a set of tables something like this:

              Contacts (one record for each person that initiates work flow such as by calling to complain about a product.)
              Complaints (one record for each complaint initiated)
              Stages (one record for each "stage" in the workflow)
              StageDetailTables (optional, for each type of phase, you can define a set of fields customized to the needs of that type of phase. You may not need such tables, if you incorporate sufficient fields into the Stages table--it depends a lot on your business model and your preferences as a developer.)

              Contacts----<Complaints----<Stages----StageDetailTables      (one----<many)

              Each time you move a complaint to the next step in your workflow, you'd create a new Stages record to document the change. By reviewing the entire set of Stages records for a given complaint, you'd see a complete history of who did what and when to resolve the complaint.

              • 4. Re: Post: Workflow control, my approach
                electric_soul

                Hello

                Well, nice idea with that protocol. This might come in handy, because it is easy to read. Right now I have a global script that I use. It saves the records in a $$variable when you enter a record. When you save a record, it compares all fields and looks for changes and writes those into a LOG table.

                But that's not quiet want i am looking for or I am confused ;)

                I want, should have said that ealier, a global solution. All my processes shall be controlled by a roadmap. This roadmap will be read when a user interacts. And depending on the user action, someting happens". You could say, that all my If statements that I would usually programm for each solution, are stored in this roadmap. Then I'll need a script that is able to read that roadmap and gives the user the possibilitiy to choose what can be done next, depending on the current status.

                Now lets say, you send the complaint to repair. Now you have the status "in repair". Now you decide, before anybody is trying to repair anything, "Lets consult an ingeneer ,and ask if we have something better to offer, than just a simple repair". Now you need to choose an action and click on submit. This action might be called "invole engineer". BUT this action is missing. Why? Because the status the record in currently in, has not been defined in the roadmap. therefore there is no action, that a user could choose.

                Solution is. You add an action for the current status in into the roadmap. Now you can select this action, press Submit and the status changes to the next status, that has been connected with the action.

                :)   this solution has the advantage, that you do not have to script so much. You can even store the contacts, that have to be informed when you execute an action.