Need some feedback to incorporate signature fields using reference data

Answered

Our employees are part of a weekly safety meeting and they need to sign in to show they attended. Currently I have one form set up for each operation and each employee has their own signature field. Each time someone is hired or someone leaves, that form is updated. 

I planned on consolidating all locations into one form and each screen would be a different location.

I'm thinking that there is a way to auto populate or at least set this up a bit cleaner using reference data and field conditions. I know I can't populate a name for a signature field using reference data... any other ideas?

Maybe use reference data to populate short text fields then have the signature fields set up with field conditions when there is a name in the short text field?

 

-1

Comments

3 comments
Date Votes

Post is closed for comments.

  • Official comment

    2024 Update:

    The Community is getting cleaned up! If you are stumbling across this post after September of 2024, this is the most recent solution or answer to the request in this post.

    This can be solved with Dependent Reference Data on a Table and making the Signature Field Required. Visit the Help Center article, "Configure Dependent Reference Data in the Builder" to learn more about how this type of reference data can filter choices in a drop down menu.

    Based on current form building recommendations, the condition is probably redundant if the signature is required.

  • Danielle,

    GREAT IDEA-  setting up reference data to populate short text field and then have the signature fields "appear" once there is a name would be a great way of tackling this problem.  You'd want to set up your condition for the signature field to be "Employee Name is 'not equal' to [blank]"

    It'll end up looking something like this:

    This way, the signature field will only appear once there is an entry in the employee name field. 

    0
  • Hi Danielle, 

    I'm going to chime in with how I'd think about this, but I'll also poke some of the folks on the Support team who might have a different idea.

    As you suggested, I'd use some good old fashioned Reference Data. More specifically, dependent Reference Data (for background, here's a help topic on this). This would allow a user to select their location from a dropdown, and when they proceed to the next screen, there would be a dropdown with employee names that only apply to that location. That would require two Reference Data files: one with the list of locations and one with the locations corresponding to each person. The first screen would have the location dropdown referencing the first file. The second screen would have a dropdown with the second reference file, set up to have the reference screen be the previous screen, and the reference field being that location dropdown. That way they'd limit the number of users to be only those in that location, and they wouldn't even see the other people or locations. 

    Here's what the first screen would look like: 

    My Reference Data file there is one column called Location, with Location 1, Location 2, Location 3 as rows.

    And the second one, referencing the first: 

    The Reference Data file there is two columns; the first Location, the second person's Name. Each person from Location 1 has Location 1 listed in column 1, etc.

    You could also loop part of the this to capture all the data from one location in a single submission. In that case, I'd probably put the employee name as the key field and have the signature portion (and maybe a date field) as the looped screen. The end result would be one submission per location, with each person and their signature on a separate row. 

    Here's what that looks like: 



    -1

Didn't find what you were looking for?

New post