You are viewing limited content. For full access, please sign in.

Question

Question

Customized Default Value for Fields/Variables

asked on November 16, 2020

I need of some assistance or best practice tip(s).

 

Process Breakdown (Tried to shorten it as much as possible 😊):

  1. Inventory Manager submits annual survey (Public Portal form)
  2. Internal Staff Reviews application for completion and/or errors
  3. If approved, the survey is responses are saved into a custom db table where we present the submissions in a spreadsheet so they can be scored.
  4. If rejected, the submitter receives an email detailing the edits/corrections and with an url** that leads to a new survey with their previous responses already entered.

**I used a GUID as a URL parameter that triggers a lookup to the table storing the response data

  1. Once the submitter completes and submits the survey the process starts over again.

I am looking for a way to isolate, in the custom table, the submissions that were submitted by the same organization. For example, if ABC Works submitted an initial survey and they also had to make corrections when we viewed the data in the table there would be two rows of data for the same organization.  I am thinking of a field that can have a defaulted value generated by Laserfiche that would be unique to the entity submitting the survey (like an assigned ORG-ID). I also do not want to trust a field like organization name or any manually entered name due to variety of randomness that can result from human error (ABC Works vs. ABC Works Inc.)

Has anyone had a similar issue the resolved or have any guidance on this type of situation.?

 

 

P.S. Some more background info.

  • Workflow assigns the GUID value based on the Forms Instance ID.
0 0

Replies

replied on November 20, 2020

It sounds like you're storing the completed forms and the "needs rework" forms in the same table, but the latter also get a GUID. In that case, I'd have the workflow that saves the data first check if the GUID field is populated on the form. If so, then delete any existing records in the table with that GUID before saving the new data.

That could also help prevent someone from reusing the rework URL and duplicating their submission.

1 0
replied on November 20, 2020

Thanks Scott, My actual solution (so far solution that is) to this was very similar to what you said. I used WF to validate (using process variables from Forms) whether or not the submission was new or not (New would not have app id whereas a correction application would have the app id). From there I created a separate workflow that used the already existing app_id instead of generating a new one.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.