hi,

I'm having trouble getting workflow variables to work as I intended. Perhaps I'm doing something wrong.

I have the following simple process:

The workflow is as follows:

  • A Client makes a Request by filling in a few things in a form.
  • The Client enters his name and some other info in the form and sends it.
  •  
  • Then an Employee logs in and sees that there is a request to process.
  • When the Employee opens the form, he should see the information that the Client entered as read-only.
  • He can then fill in a Request ID and update the status in the form and finish.
  •  
  • Lastly, the Client logs in again and sees that his request has been processed.
  • He opens the form and it has all the fields he filled in as well as fields updated by the Employee all as read-only.
  • He can then print this out.

As you can see, it is quite a simple workflow.

Several questions:

  1. It is not clear to me if I need 1 form or 3 forms. If 3 forms, then I would have to explicitly add Read-Only Textfields to Form 2 + Form 3.
  2. In the Workflow Designer, I saw that you can create workflow variables and then specify which activity can edit or only view them.

Problem:
I tried to do this with both 1 form or 3 forms, but when the Employee logs in and opens the form, the fields filled in by the Client are not loaded.

But the waiting icon is there. After awhile I click on the screen and the waiting icon disappears and the fields are not loaded from the last activity.

Can it be that there is a problem loading the variables?

What is the sequence of steps I need to get this to work?

Thanks,

Clara

  • No labels

6 Comments

  1. Just noticed that there was an error casting from Long to String.

    However, I expect the web app to display an error, not just show it in the server log.

    I guess I'll leave all my fields without validation for now and see if it works.

  2. NEW UPDATE:

    Just found out that if I set the type of all workflow variables in the Workflow Designer to String, then the entire workflow works as I expected.

    However, if any of those workflow variables have another type - i.e. Integer or Date

    It causes a type casting error (in the server output) when the variables are being loaded into the next form.

    I'm not entirely sure about this - but did I find a bug?

    How do I specify the textfields to be handled completely as anything other than String?

    1. Hi Clara,

      Actual data is meant to be captured and stored in the forms rather than workflow variables. The form fields can then be set to validate accordingly. Currently, workflow variables are used mainly to determine process flows and should only be set to String. It's meant to be typeless, in the sense that even if it's String, a condition such as (amount > 100) will still work.

      I guess the type option selection makes it a bit confusing and should be removed in the next version :)

      Thanks

      1. hi Julian,

        Thanks for the explanation.

        However, I still don't really understand.

        If I don't use the workflow variable to transfer values between forms, then how do I do it?

        I want the value of Field A in Form A to show up as read-only in Form B.

        Please explain.

        Thanks,

        Clara

        1. Hi Clara, there are a few ways to do this. First, you can insert Form A as a subform in Form B. You can take a look at Figure 3.5 of this article for reference.

          Another way is, insert a Read-Only Text Field in Form B, and give it the same name as Field A in Form A, in advanced properties. Assuming Form A and Form B are using the same table. So for example, if we have a text field in Form A, named as addressLine1, we could have this value displayed in Form B, by naming a form field as addressLine1.

          Besides, we can also display addressLine1 in Form B, by using Hash Variable in custom HTML. For example:

          <ul>
          <li>Address (Line 1): #form.addressLine1#</li>
          </ul>
          1. hi Tiensoon,

            Subform seems like the simplest choice - and is the option used in the Travel Request example.

            Also helps that I don't have to create multiple forms for the same customer input fields.

            Perhaps a more explicit pointer to subforms in the Knowledge Base would help others to not go down the wrong path. :)

            Thanks,

            Clara