What is the best approach to collect a survey data from a set of people or group?

I think there are a few key questions that need to be addressed before we get into specifics of the design.  The answers to these questions I think radically alter which approach is best:

1.  How many people are expected to answer the survey?

2.  Are they authenticated users of your application? (If not, Appian Portal is the way.)

3.  Do you need to gather data from the entire group or set of people, meaning that the survey can't be complete before all have answered?

4.  Rephrase of the question above, I guess, is the survey mandatory for the people being asked or optional?

5.  How quickly do you need results?

6.  Do you need the results to be anonymous?  The system may know the identity of each answer, but the people looking at the data shouldn't be able to tell?

7.  How many questions?  Are the questions dynamic, as in how you answer some questions determine what you get asked?

8.  Could this same survey be presented again, or could the same framework be utilized for future surveys?

Answering these is the start of determining a good approach.  A quick mental calculation arrives at 512 or possibly 1024 different combinations of answers.  So yeah, we really need to narrow it down below 1000 possible best approaches to make a survey.

Hi Dave,

Thanks for your the reply and asked questions.

Please see the following answer for your above questions.

1. There are 1000+ people from a group.
2. Only Authenticated users
3. From the entire group
4. Mandatory by all users from the group
5. User need to submit the form within 2 days
6. Not anonymous. Only need to save the data into the database table.
7. There will be 4-5 questions only.
8. This can be same in the future.

Thanks once again!

Regards,

Shubham Kumar

Fantastic.  Glad you have the answers so ready.

For your use case, some might argue that a couple of days is too long to wait, that could be a long waiting process.  However, I think it's actually not too bad.

I'd create an overarching process that finds all the users that need to be assigned a survey, finds the survey that needs to be assigned (this way the process can be reused with simply a different survey input, perhaps saved in a table from another small PM, so it grabs the survey from the most recent row).  It creates an a!startProcess for each user in the group using MNI.  Then the orchestrator process dies and goes to be archived.  a!startProcess is key for all of your surveys to be load-balanced.

You've generated 1000 plus processes in the system, each assigns a task to one assignee, the specific user.  Put a timer and possibly some escalations on the task to make it appear more urgent to the user as the deadline approaches.  You could possibly chain two user input tasks together, day 1 is "Please fill in this survey", and day 2 is "No seriously, fill in this survey!" You need to make sure that the process dies after 2 days, and add some reporting on the flow that kills the process after 2 days so you have a record of those who are non-compliant.  If you don't add the kill switch at 2 days, this does become very inefficient.

The advantage of doing it that way is that the faster the users fill out the survey, the more processes are done and ready to be archived.  If you did a synchronous process at the beginning, the orchestrator would need to wait for all the surveys to be filled before it's engine could stop running it, and the RAM could be freed for other things.

You could add some reporting on the flow between the escalation, or even better some reporting when users have completed the survey that can go into charts and a list of people who still haven't filled it in so their supervisors can gently remind them.

This is what I would present to client as a first spitball of our possible approach.