1
0
-1

Hi all,

I am currently building a form which is designed to be multi-tenant.

Every tenant may have different rules for show/hide, editable/uneditable for the same field.

I will be able to get a prefill data from the source system indicating which tenant it is for, what is the best way to design the form?

 

For example in the form we have "First Name", "Last Name"

We have possible 3 Tenants "Company A", "Company B", "Company C"

"Company A" wants if prefill data for first name, last name exists, then we make the fields uneditable, otherwise the first name and last name is editable.

 

"Company B" wants if  prefill data for first name, last name, exists we make the fields uneditable, otherwise first name and last name fields are hidden.

 

"Company C" wants the first name, last name to be editable all the time.

Many Thank

Mike Chen

 

 

    CommentAdd your comment...

    1 answer

    1.  
      2
      1
      0

      Hey Mike, my advice would be:

      1. Group the fields into a common container (block) and apply the visibiliy/editability rules to the container, not the individual fields.
      2. Add data fields in the form that will be used store the visibility and editability preferences for these field sets and have the visibility/editability rules check these preferences. Of course these fields should not be saved in the submission data.
      3. Add a Form Load rule to set these preferences in these data fields depending on the tenant. This way it is all controlled in one place and you don't have multi-tenant logic scattered throughout your form.
      1. Ben Warner

        In fact, you don't even need to use data fields. You can just set values of unbound data elements on the data object, e.g.:

        data.$usName = false; // Editability preference for name fields
        data.$shName = true; // Visibility preference for name fields

        Then check the value of these data elements in your visibility / editability rules.

      2. Mike Chen

        what is data.$usName, and data.$shName mean? Is that some implicit variables in Maestro?

      3. Ben Warner

        They are just made up names for unbound data elements. There is a convention in Maestro to use a $ at the front of the variable name for unbound data elements so that they don't interfere with bound data elements that may have the same name.

        I just prefixed the variable name with the rule type code as found at the bottom of this page:

        Advanced Debugging of Maestro Forms

        us = Editability rule

        sh = visibility rule

      CommentAdd your comment...