I think this is a great feature but the current implementation is rather barebones. Most of the missing form design features have already been posted by other users in this thread so I’d like to focus more on data privacy/administration.
My community would like to use application forms mostly as a user management system. For that purpose forms should preferably function similar to the flagging system whereas the admins can decide who can see the applications and who can respond to them. Otherwise, if we use the current forum template personal information of new users would end up on a public forum category which is not desirable. It would also be brilliant if these forms could be tied into user group management, e.g. if a new member applies to join the community and a moderator approves their application they should automatically gain trust level x, user group y and lose user group z.
As an example, these are some of the features which would be amazing to become native to Discourse: discord bot Appy. Currently, we use the discord bot Appy but it causes additional workload for admins and moderators to keep everything in sync.
To me that is not an adequate solution. This would mean that all new recruits would see the applications of other recruits, making their private information (email, age etc.) far more visible than it should be.
That’s why I would require the application form to function more like the flagging system works. Where new users can create inputs but only staff (admins, moderators, selected user groups) can actually access those inputs.
EDIT: one way this could work if there was a category setting which makes it possible that topic authors can only see their own topics.
This sounds like group messaging might be more appropriate for you, i.e. applications are made by sending a message to a group rather than creating a topic in a category and only members of that group (plus the sender) can see the messages.
Unfortunately form templates aren’t available for group messaging. I think I asked about this in the context of support enquiries, someone did, but I don’t know whether or not that’s something intended for the future.
This has been discussed in other topics, e.g. #4 (and subsequent replies) in Offering "private support" as part of a public support community, where my impression has been that they don’t want to do it as it would add a lot of complexity to category permissions for something which is already there with group messaging.
It’s also more flexible with group messaging because participants can be added/removed as appropriate. E.g. if recruiting for a technical role, you might have applications go to an HR group and once they’ve done sanity checks on the application, they could add the relevant technical group as a participant.
I would definitely like to see form templates extended into group messaging eventually for scenarios like these.
Unfortunately that wouldn’t fully cover our needs as we require classic application form features:
Drop Down Menus
Multiple Choice Answers
Formatting Tools
Conditional Fields (if the answer to question A is B then show field C)
Ability to review applications by moderators/admins
Long-term storage of applications for a changing set of moderators/admins (that’s why group messaging won’t work for us either, as people join/leave the staff team over time)
Adequate data privacy - i.e. users should only be able to see their own application
Automated user management (if application A is accepted give user group B and/or remove user group C).
I think a short-term fix would be to introduce a new category setting that admins can tick called “users can only see their own topics”. This would cover most of the points raised above as the Experimental Form Template could be used without making it visible to every user of a certain user group. Then maybe over time the remaining functionalities mentioned by other posters here and me could be added to the form by the devs.
I’ve tried Custom Wizard before but it somehow broke some default discourse setting fields in the admin section. After that, I deactivated the plugin and the discourse setting fields worked normally again, maybe the plugin wasn’t compatible with the latest version of discourse at the time.
Thank you! Wasn’t aware of this third-party plugin (so far I’ve limited myself to official plugins only after I ran into some issues with Custom Wizard).
