These are the fine-tuning steps in the App creation process. These settings can be found in the tab named Configuration (2nd tab in Edit mode of the App)
Using this feature, reviewers of the app can assign different statuses like Accepted, Rejected, In Progress, On Hold etc. to the submissions created by the end users. Submission owners will be notified on each status change unless such settings have been disabled.
Many times we need to print documents with the values that we input in our Apps. Using this feature, we can upload a document template or write it ourselves, pick values from the submissions of our app, merge template and the dynamic values and create a final merged PDF document. DEEP DIVE
Once the app is designed, we need to assign it to other users of our org. This is a two-step process. We first need to invite those users using their email addresses to sign up on our Clappia Workplace. Then we assign the app to those Workplace users. More details here.
We enable this option if we don't want users to sign up to use the app. We can share the link of the app and anyone can see the App and submit data just by visiting the link.
More Advantages: No need to add users to the app and the Workplace, and no need to buy licenses for each user,
Disadvantages: You can't assign statuses to a submission as the data flow is just one way and users can't submit data from the mobile app without internet (they can visit the mobile URL to submit though).
We can connect our Clappia apps to Google Sheets so that all submissions get sync'ed to Google Sheets in real time. More about Google Sheets connection here.
By default, all apps have a submission button. We can disable this to create Apps that don't require submissions.
Some of the use cases where people use this feature are -
Other than the individual field validations, we can add validation conditions for the entire submission. This can be useful if we want to put a validation condition which involves multiple app fields. For example, Project End Date >= Project Start Date, Check-out time > Check-in time, Check-out time - Check-in time >= 6 hours.
Multiple such conditions can be defined, each with its own custom error message. While writing the validation conditions, we can use @ to get a drop-down of all the field names that be used in the conditions.
The example below shows a couple of validations on an Attendance app. The validations ensure that while checking in, the user selects the current time for Check-in, and later, while checking-out, again the user selects the current time for Check-out.
More examples of custom validation