Hi everyone,
I want to talk about e-forms (and e-form groups, and checklist workflows). This is more of a brainstorming thread than anything else. I have thoughts™ about these things, but I'm sure you do too. By having this discussion, I'm not in any way suggesting that any of this will happen this year, or even next year. Frankly, the code for e-forms in particular is a mess, and rewriting it to be cleaner with absolutely no change in functionality is probably 9-12 months of work, all on its own.
But that said, it's work I think is worth doing. And when we get to it I'd like to have a plan. (This is some truly unknown future time -- we definitely won't be starting on this in the next 6 months, and I doubt we'll start on it soon after that either)
I've got some of my thoughts below, just to get things started. But I'm also interested in what other people think. Feel free to comment on my ideas, but also throw out your own ideas, or your problems even if you don't have a proposal for a solution. What annoys you about e-forms and/or checklists? Have you seen other products we ought to be taking ideas from to make things easier to use?
----------
We all recognize that checklists are complex. But I think they are more complex than they ought to be. Right now, there are one-off e-forms. And there are e-form groups. And there are checklists. But here's the thing that bugs me: what's the difference between a one-off e-form, and a checklist on a group with one form in it with one stage and no tasks? Functionally these things are basically the same. So I'd like to combine them into a single "Workflow" tool.
I'm taking inspiration here from Jira. I don't know how many people have configured a workflow in Jira before, but it's dreamy. You create a workflow. They have templates you can start with, or you can start with a blank slate. You create "statuses" (which are the equivalent of a "stage" in sunapsis) as boxes on a canvas. And then you create "Transitions" between statuses (stage movement rules) by drawing arrows between your boxes. You can trigger forms to be filled out on transitions, and notifications to be sent, etc.
Obviously, this doesn't all translate to sunapsis. Jira doesn't really have "forms" or "tasks" the same way. But a lot does translate. You create a workflow. Maybe we even have template workflows. It creates a stage and a group. Then you have buttons to add other stages, e-forms, and tasks. You can have transitions between stages, and associate emails, letters, templates, or closure rules to the transitions.
This probably demands some adjustments - if we take everything exactly as I've written it, with the ability to only have a communication based on a transition, if you want to have an email go out when approving/denying an e-form, you'd have to have at least 2 stages (form submitted, form processed), and movement rules between them (Approve Form: Moves from "form submitted" to "form processed" when form is set to Approved and triggers an email, and Deny Form: Moves from "form submitted" to "form processed" when form is set to Denied and triggers an email). But by the same token, checklist emails and e-form emails become the same thing, so there's not two places to configure the same thing any more.
E-Form/Checklist Improvements [Vendor Post]
Re: E-Form/Checklist Improvements [Vendor Post]
Hi Tim,
I'm very happy to see this post. Thanks for taking the time to share your thoughts and opening up the topic for discussion.
Here are a few checklist related thoughts. I'm just throwing things out there so no pressure to respond.
I'm very happy to see this post. Thanks for taking the time to share your thoughts and opening up the topic for discussion.
Here are a few checklist related thoughts. I'm just throwing things out there so no pressure to respond.
- I don't quite get the purpose of eform groups. Maybe checklists weren't always a thing? It seems like they could disappear and any functionality they offer could be handled by checklists.
- Related to eform groups, as you know, I really like to use eforms on multiple checklists so I dont have to create and maintain duplicates for each campus/admit group/etc.
- The more I think about your single "workflow tool" the more I think I get it. Basically, everything goes through a checklist? For my interest of sharing eforms, If you can move things like template, alert, and eform email configurations out of eform configuration and into the individual checklists it makes it easier to create eforms that are easily shared between checklists. Basically, anything relating to the content of the actual e-form (including some modify extensions) could remain in e-form configuration so you can maintain it in one place and any actions that are taken would be configured in each checklist.
On the theme of sharing things between checklists, maybe communications could be handled in a similar way since default communications might be affected? - I don't like the idea of relying on stage movement to handle eform status emails. I think that adds an unnecessary level of complication (more stages), especially when there are multiple eforms to be completed in a particular stage. I think the current checklist communication options are pretty good.
- If you do go with a workflow tool idea, it sounds like that would complicate things a little when creating what would currently be a standalone eform. You mentioned the idea of workflow templates so maybe create a new checklist type that automatically only has one stage, no tasks, isn't visible in Checklist Management, etc so that single eform process is as simple as possible and the checklist stays out of the way of "normal" checklists. But please allow the checklist type to be changed if someone decides it needs to be more complex down the road.
- Checklist tasks are awesome but it would be really great to also have a way to automatically or manually add multiple "tags" (Ex. UG, Honors, whatever) to a person's checklist and be able to use them for filtering, stage movements, etc. Maybe this could be accomplished with the existing Tasks but somehow make it possible to group tasks into one column? Maybe tasks could be expanded to allow input similar to an eform text field or a dropdown field so we can see more than Approved, Required, etc.
Re: E-Form/Checklist Improvements [Vendor Post]
Hi Tim,
I'm excited that you're going to look at revamping eforms, etc. I don't know that I have a lot of great input up front, but I'll keep thinking about it.
As far as checklist functionality goes, I agree with Bryant that it is helpful to have the option to send the email from the checklist AND from the eform. For instance, at UC Davis, we have several approval email templates and sometimes several denial templates. This is so that advisors can send targeted information as needed. It would be very hard to have a checklist decide which email to send, so being able to choose the correct template to email the student is important to many of our workflows. (An example of this is our eform for students who are taking a leave of absence. We have "eligible for reactivation if returning for XXX term" emails for each term and a separate "new I-20 needed for your planned return" approval email so that the student knows what to expect.)
I also agree that there is likely no functional difference between an eform group and a checklist other than the checklist offers lots of bells and whistles that we LOVE!
As for Briant's tagging idea, I love it. I am currently "tagging" records with custom task extensions that automatically approve/NA certain tasks on a checklist. A few examples: The incoming I-20/DS-2019 checklists pull admit data (admit date must be in the future to flag) for Academic Level, Admit Term, and certain special degree programs that need special routing. On several other checklists I am using tasks to "tag" records is with the SEVIS status (Approved = Active, Conditionally Approved= initial/transfer, Denied = completed, inactive-deactivated or terminated, and the trickiest one for me to code...Submitted (blue check) for those in the grace period. The SEVIS status flag helps me automate some stage movement based on the most current status.
I know Lucy (UCSC) was looking for a way to tag the assigned Advisor in checklist. She may end up doing a custom task using the same logic used to assign advisors and each advisor has their own task "status", but it would be great to have additional flexibility to tag checklists automatically without custom logic.
Thank you!
~Emily
UC Davis
I'm excited that you're going to look at revamping eforms, etc. I don't know that I have a lot of great input up front, but I'll keep thinking about it.
As far as checklist functionality goes, I agree with Bryant that it is helpful to have the option to send the email from the checklist AND from the eform. For instance, at UC Davis, we have several approval email templates and sometimes several denial templates. This is so that advisors can send targeted information as needed. It would be very hard to have a checklist decide which email to send, so being able to choose the correct template to email the student is important to many of our workflows. (An example of this is our eform for students who are taking a leave of absence. We have "eligible for reactivation if returning for XXX term" emails for each term and a separate "new I-20 needed for your planned return" approval email so that the student knows what to expect.)
I also agree that there is likely no functional difference between an eform group and a checklist other than the checklist offers lots of bells and whistles that we LOVE!
As for Briant's tagging idea, I love it. I am currently "tagging" records with custom task extensions that automatically approve/NA certain tasks on a checklist. A few examples: The incoming I-20/DS-2019 checklists pull admit data (admit date must be in the future to flag) for Academic Level, Admit Term, and certain special degree programs that need special routing. On several other checklists I am using tasks to "tag" records is with the SEVIS status (Approved = Active, Conditionally Approved= initial/transfer, Denied = completed, inactive-deactivated or terminated, and the trickiest one for me to code...Submitted (blue check) for those in the grace period. The SEVIS status flag helps me automate some stage movement based on the most current status.
I know Lucy (UCSC) was looking for a way to tag the assigned Advisor in checklist. She may end up doing a custom task using the same logic used to assign advisors and each advisor has their own task "status", but it would be great to have additional flexibility to tag checklists automatically without custom logic.
Thank you!
~Emily
UC Davis
Last edited by ejtaylor on Thu Jun 11, 2020 9:13 pm, edited 1 time in total.
Re: E-Form/Checklist Improvements [Vendor Post]
Why do e-form groups exist? It's historical, like you guessed. Single e-forms were added in v2.0 and e-form groups in v2.5. Checklists didn't exist until v3.0. That's the reason for a lot of quasi-duplication in the system. Form Letters and Checklist letters fall in the same category. As do e-form emails and checklist emails. But this plan would essentially hide e-form groups away under the hood. They'd always be there, but no one would have to know about them.
Some of these things provide slightly different levels of functionality, so they're not straight duplication. Emails are a particularly good example. E-form emails happen in real-time, while checklist emails happen overnight. But beyond that (admittedly significant) difference, I think anything an e-form email can do, a checklist email can do too. So ultimately, I'm not so much talking about removing things, as merging things together. Right now, e-form emails have an option to say "send automatically, or don't." If we added that option to the checklist emails instead, then you don't lose what the e-form emails can do (you can still choose which email to send on approval), but you also gain the ability to choose what email to send on task approval, or stage movement.
Bryant, I would love to talk about how *you* use checklists because you're the only one doing it that way, as far as I know, and I still haven't grokked it. I "understand" that you're using checklists to avoid having multiple copies of an e-form. But it's not clicking for me exactly how having multiple checklists that use a group of e-forms solves that problem.
I wonder if having some universal libraries of puzzle pieces might help with this problem, and also the default email issue that you brought up. If we had libraries of e-forms, tasks, emails, and letter pieces, then you could assemble a workflow out of them perhaps. and of course, add new puzzle pieces if there wasn't one to fit your needs already.
The tag idea is one that probably deserves some additional discussion too. I'm going to start by renaming it to "label" because "tag" is already a word we use to describe something else. But maybe labels could work like templates: they associate a data point from another table to the checklist (sevis status, major, student group).
As for Lucy's issue, we already have "tags" (the stars at the left end of the row) that are a proxy for assignment. We don't have a way to auto-assign checklist rows like we have for alerts. But if Lucy's looking at having to write something anyway, she could write a script to insert rows into jbChecklistTags auto-assigning checklists to people. (This is one of those half-assed features - it won't show up in your case assignments, but if you open the stage, it will mark all your stuff with a yellow star, and you can filter by that, I believe).
Some of these things provide slightly different levels of functionality, so they're not straight duplication. Emails are a particularly good example. E-form emails happen in real-time, while checklist emails happen overnight. But beyond that (admittedly significant) difference, I think anything an e-form email can do, a checklist email can do too. So ultimately, I'm not so much talking about removing things, as merging things together. Right now, e-form emails have an option to say "send automatically, or don't." If we added that option to the checklist emails instead, then you don't lose what the e-form emails can do (you can still choose which email to send on approval), but you also gain the ability to choose what email to send on task approval, or stage movement.
Bryant, I would love to talk about how *you* use checklists because you're the only one doing it that way, as far as I know, and I still haven't grokked it. I "understand" that you're using checklists to avoid having multiple copies of an e-form. But it's not clicking for me exactly how having multiple checklists that use a group of e-forms solves that problem.
I wonder if having some universal libraries of puzzle pieces might help with this problem, and also the default email issue that you brought up. If we had libraries of e-forms, tasks, emails, and letter pieces, then you could assemble a workflow out of them perhaps. and of course, add new puzzle pieces if there wasn't one to fit your needs already.
The tag idea is one that probably deserves some additional discussion too. I'm going to start by renaming it to "label" because "tag" is already a word we use to describe something else. But maybe labels could work like templates: they associate a data point from another table to the checklist (sevis status, major, student group).
As for Lucy's issue, we already have "tags" (the stars at the left end of the row) that are a proxy for assignment. We don't have a way to auto-assign checklist rows like we have for alerts. But if Lucy's looking at having to write something anyway, she could write a script to insert rows into jbChecklistTags auto-assigning checklists to people. (This is one of those half-assed features - it won't show up in your case assignments, but if you open the stage, it will mark all your stuff with a yellow star, and you can filter by that, I believe).
Re: E-Form/Checklist Improvements [Vendor Post]
Hi Tim,
It's entirely possible I'm overthinking or missing something with our eform group checklist situation. If it's worth it to you and you have the time I'd be happy to do a quick call sometime. I'll also create a separate post at some point in the near future to open up a discussion regarding multiple checklists so it doesn't get this conversation too off topic.
I like the idea of a central library of pieces that can be used to create workflows. I think there's a lot of potential in using wildcards to create "universal" pieces that can be used in multiple places to avoid duplication. Might make Shareables even more useful. Maybe expand the use of meta information to help customize e-forms based on the checklist they're being viewed through, emails depending on what stage/task triggered them, etc. Sounds like a lot of work for you guys so I better stop.
Splitting hairs here but would "attributes" possibly be a more accurate name than labels? Being able to use a template to add a label from table data would be great. I'd also like to be able to create something like task extensions to allow for automatic updates when the data feed runs.
Minor checklist wishlist item if you rework any of the email functionality: it'd be great if we could send the queued checklist emails multiple times a day so clients are notified sooner and can get through the process faster.
It's entirely possible I'm overthinking or missing something with our eform group checklist situation. If it's worth it to you and you have the time I'd be happy to do a quick call sometime. I'll also create a separate post at some point in the near future to open up a discussion regarding multiple checklists so it doesn't get this conversation too off topic.
I like the idea of a central library of pieces that can be used to create workflows. I think there's a lot of potential in using wildcards to create "universal" pieces that can be used in multiple places to avoid duplication. Might make Shareables even more useful. Maybe expand the use of meta information to help customize e-forms based on the checklist they're being viewed through, emails depending on what stage/task triggered them, etc. Sounds like a lot of work for you guys so I better stop.
Splitting hairs here but would "attributes" possibly be a more accurate name than labels? Being able to use a template to add a label from table data would be great. I'd also like to be able to create something like task extensions to allow for automatic updates when the data feed runs.
Minor checklist wishlist item if you rework any of the email functionality: it'd be great if we could send the queued checklist emails multiple times a day so clients are notified sooner and can get through the process faster.
Re: E-Form/Checklist Improvements [Vendor Post]
Tim,
Thanks for reaching out. Here are a few thoughts:
- One e-form for multiple checklists. I could totally get behind the idea of 'tools' that could be utilized in many ways. Here's an example: I have one 'Passport Information' e-form. I have several checklists that use the 'Passport Information' e-form. If I could place the Passport Information e-form in a "library" of e-forms, then I could apply it to any e-form group/checklist, I wouldn't need to duplicate the e-form, and there would be ONLY one. Right now, I have twelve different copies of the same e-form. If I need to make a change to the Passport Information e-form, I need to make that change twelve times. AND, if you add the templates and the communications to that library, it would be totally efficient.
- My issue about the "tags" is not solved by the stars. You can't sort by the stars or assign them - they are self-assigned. If you have 3,000 students on a checklist and five advisors, and you want to know which ones are assigned to which advisor, those stars do nothing. I can change the colors of the star, but I can't sort. And, there are a limited number of stars, so then I have to start using the boxes and X and @ and it's just ugly. How about a custom field that is sort-friendly and not overwritten by the datafeed?
I'll come back with more.
Again, thanks for reaching out and asking questions.
Lucy Zoe
Thanks for reaching out. Here are a few thoughts:
- One e-form for multiple checklists. I could totally get behind the idea of 'tools' that could be utilized in many ways. Here's an example: I have one 'Passport Information' e-form. I have several checklists that use the 'Passport Information' e-form. If I could place the Passport Information e-form in a "library" of e-forms, then I could apply it to any e-form group/checklist, I wouldn't need to duplicate the e-form, and there would be ONLY one. Right now, I have twelve different copies of the same e-form. If I need to make a change to the Passport Information e-form, I need to make that change twelve times. AND, if you add the templates and the communications to that library, it would be totally efficient.
- My issue about the "tags" is not solved by the stars. You can't sort by the stars or assign them - they are self-assigned. If you have 3,000 students on a checklist and five advisors, and you want to know which ones are assigned to which advisor, those stars do nothing. I can change the colors of the star, but I can't sort. And, there are a limited number of stars, so then I have to start using the boxes and X and @ and it's just ugly. How about a custom field that is sort-friendly and not overwritten by the datafeed?
I'll come back with more.
Again, thanks for reaching out and asking questions.
Lucy Zoe
Re: E-Form/Checklist Improvements [Vendor Post]
Hi Lucy,
I agree that tags leave a lot to be desired. It would be good to make them more informative - in v3, you could hover over them to see who the assigned user was. That went away for v4, but I don't really know why. And it would make sense to tie them into the case tracker, or at least be able to assign them the same way you can with alerts. But of course none of that exists right now.
Since Emily said you were looking at doing a custom task extension for this anyway, writing a query to insert user names and checklist id's into jbChecklistTags isn't really very different from inserting statuses and checklist id's into the task queue. And then you have worked around the problem of how to assign stars to other people by manipulating the data directly.
As for reporting based on those tags, under Views: Miscellaneous Queries, there's a view called "Checklist Tags." You can use that to see who has what assigned.
I agree that tags leave a lot to be desired. It would be good to make them more informative - in v3, you could hover over them to see who the assigned user was. That went away for v4, but I don't really know why. And it would make sense to tie them into the case tracker, or at least be able to assign them the same way you can with alerts. But of course none of that exists right now.
Since Emily said you were looking at doing a custom task extension for this anyway, writing a query to insert user names and checklist id's into jbChecklistTags isn't really very different from inserting statuses and checklist id's into the task queue. And then you have worked around the problem of how to assign stars to other people by manipulating the data directly.
As for reporting based on those tags, under Views: Miscellaneous Queries, there's a view called "Checklist Tags." You can use that to see who has what assigned.
- custom report.png (17.48 KiB) Viewed 9788 times