General Discussions

Hey Cayuse Community,

As we gear up for even more exciting updates, we want YOUR input! We believe in creating software that truly meets your needs, and your feedback is crucial.

Our planned enhancements are:

• Incorporating And/Or logic to support more complex workflows
• Supporting multi-level reviews based on your institutional unit hierarchy

We want to give you more power over your workflows so that routing becomes even smarter.  These enhancements will be coming at you in 2024.

Our team has a few questions that we'd love for you to answer:

1. Tell us about your most common routing scenario.
   1. How well does Sponsored Projects 4.0 support this scenario?
2. What improvements would make your routing tasks easier?
3. Can you share specific examples of your organization's unit hierarchy that you would like to incorporate into the routing process?
4. What challenges do you face in managing routing for projects that involve multiple units?

Feel free to share your thoughts, experiences, or any specific use cases you have in mind.  Dream big!  What do you wish you could do with routing that you cannot do now?  Your feedback will directly shape the future of this product.

Comment below with your insights, and let's make Sponsored Projects even better together.

Best,

------------------------------
Chelsea Phelan
Product Manager
Cayuse
------------------------------

Hey Cayuse Community,

As we gear up for even more exciting updates, we want YOUR input! We believe in creating software that truly meets your needs, and your feedback is crucial.

Our planned enhancements are:

• Incorporating And/Or logic to support more complex workflows
• Supporting multi-level reviews based on your institutional unit hierarchy

We want to give you more power over your workflows so that routing becomes even smarter.  These enhancements will be coming at you in 2024.

Our team has a few questions that we'd love for you to answer:

1. Tell us about your most common routing scenario.
   1. How well does Sponsored Projects 4.0 support this scenario?
2. What improvements would make your routing tasks easier?
3. Can you share specific examples of your organization's unit hierarchy that you would like to incorporate into the routing process?
4. What challenges do you face in managing routing for projects that involve multiple units?

Feel free to share your thoughts, experiences, or any specific use cases you have in mind.  Dream big!  What do you wish you could do with routing that you cannot do now?  Your feedback will directly shape the future of this product.

Comment below with your insights, and let's make Sponsored Projects even better together.

Best,

------------------------------
Chelsea Phelan
Product Manager
Cayuse
------------------------------

Hi Chelsea,

We are on 4.0 and are currently struggling with routing so I have a great deal of feedback here. I am answering your questions/responding in order below:

1. Our routing structure is: RSP/PI & Co-I/Chair(s)/Dean(s)/Business Officer(s)/RSP

   1. Cayuse struggles with supporting this structure because of the inherent architecture, specifically around "Research Team", "Team", and "Unit" and how routing builds from those siloed, and MANUAL groups as well as how those groups are assigned and maintained (Manually). There is too much manual entry complexity in Administration itself and how routing builds from it.

      1. For example, if we send the title "Chair", "Dean", or "Business Officer" AND the department/college into "People", why can't it intelligently build the routes based on that information without us having to build them into "Research Team" or "Team" and "Unit". I believe this is how InfoEd designed routing. There were NO manual processes to determine or establish the route in InfoEd.

   2. Secondarily, the issue with the Chair step or "Research Team" element may be that it pulls data from two disparate systems User/Role and Form Rules, which I think is inherently flawed. (The more moving parts theory). Notifications also tied into the "Research Team", "Unit", "Team" siloes make that system difficult to use and troubleshoot.

   3. In my opinion (again having previously used an automated system (InfoEd) for routing that worked flawlessly; there is too much manual determination in the decision-making/establishment around routing. that would be better accomplished with automated, non-manual processes.

2. Improvements:
   1. Automatic route/role determination from backend uploads per Title/Department into "People", NO manual processes. 
   2. Notifications tied to Title/Role, not Unit/Team
   3. The ability to add people to the route without having to stop and restart the route.
   4. The ability to bypass people in the route without having to stop and restart the route.
   5. Recurring reminders (notifications) sent to approve the route, not just one and done.
   6. Ability to see/confirm that notifications are sent out, see that the system is working
3. The complication in our structure seems to be Chair/Dean/Business Officer, particularly the Chair, which again is built from/determined by 2 separate variables
4. The challenges of multiple PIs from different departments and maybe different colleges is:
   1. Manual processes demand a TON of upkeep. If a Chair or Dean changes and we are not aware, it is revealed during the route. The route may have passed through handfuls of people before we find that out. In the current setup, we have to manually stop the route, change the user settings, and start the route again. I have many many routes that "die" this way as we are unwilling to have those handfuls of people re-approve a route. Getting routing approved is a challenge to begin with.
   2. The inability to skip or add a user to the route also plays into the issue described above.
   3. The MANUAL Research Team, Team, and Unit setup is not conducive to the successful routing and notification of the setup as we have it. It is inherently limiting.
   4. Recurring reminder to approve emails sent out, one email is easy to miss. We are constantly having to reach out to users to cajole them to approve the route. 
   5. A popup or user tip reminder that appears when a PI certifies the project-based COI, that they have to hang in and ALSO approve the route. They do one and think they're done. 
   6. REMOVE repeating approvals when a Chair is in that role for several of the Key Personnel and has to approve 3/4 times. Being able to bypass will help this issue.
   7. In-app reminders to "pester" people to approve routes. 

My biggest wish is that routing was intelligently generated based on credentials (title/department) that are fed into the system from the backend and not dependent on manual processes. That and flexibility with the route once it has started.

Please let me know if you have any questions or more information.

Thanks Chelsea,

Karie

Hey Cayuse Community,

As we gear up for even more exciting updates, we want YOUR input! We believe in creating software that truly meets your needs, and your feedback is crucial.

Our planned enhancements are:

• Incorporating And/Or logic to support more complex workflows
• Supporting multi-level reviews based on your institutional unit hierarchy

We want to give you more power over your workflows so that routing becomes even smarter.  These enhancements will be coming at you in 2024.

Our team has a few questions that we'd love for you to answer:

1. Tell us about your most common routing scenario.
   1. How well does Sponsored Projects 4.0 support this scenario?
2. What improvements would make your routing tasks easier?
3. Can you share specific examples of your organization's unit hierarchy that you would like to incorporate into the routing process?
4. What challenges do you face in managing routing for projects that involve multiple units?

Feel free to share your thoughts, experiences, or any specific use cases you have in mind.  Dream big!  What do you wish you could do with routing that you cannot do now?  Your feedback will directly shape the future of this product.

Comment below with your insights, and let's make Sponsored Projects even better together.

Best,

------------------------------
Chelsea Phelan
Product Manager
Cayuse
------------------------------

Wow Karie,

Your email is insightful.  We are implementing SP 4.0 in conjunction with modernization of 424/proposals and have come to the end of our weekly trainings without information built in our ABLT, so we have a somewhat abstract conceptual framework of user form rules/units/teams and how that all comes together in routing that we have not tested. 

We have been using 424/proposals for routing all grants (federal, state, private), ironically it does do what you are saying for improvements, ie - people are selected, you can add people to the route without stopping it and reorder it if someone needs to be bypassed, and multiple CO PIs are a breeze to add with their respective chair and dean/associate dean.  

Does anybody use 424/proposals for routing even though they have SP? Or have thoughts on the pros and cons of it?

Thanks

Hi Chelsea,

We are on 4.0 and are currently struggling with routing so I have a great deal of feedback here. I am answering your questions/responding in order below:

1. Our routing structure is: RSP/PI & Co-I/Chair(s)/Dean(s)/Business Officer(s)/RSP

   1. Cayuse struggles with supporting this structure because of the inherent architecture, specifically around "Research Team", "Team", and "Unit" and how routing builds from those siloed, and MANUAL groups as well as how those groups are assigned and maintained (Manually). There is too much manual entry complexity in Administration itself and how routing builds from it.

      1. For example, if we send the title "Chair", "Dean", or "Business Officer" AND the department/college into "People", why can't it intelligently build the routes based on that information without us having to build them into "Research Team" or "Team" and "Unit". I believe this is how InfoEd designed routing. There were NO manual processes to determine or establish the route in InfoEd.

   2. Secondarily, the issue with the Chair step or "Research Team" element may be that it pulls data from two disparate systems User/Role and Form Rules, which I think is inherently flawed. (The more moving parts theory). Notifications also tied into the "Research Team", "Unit", "Team" siloes make that system difficult to use and troubleshoot.

   3. In my opinion (again having previously used an automated system (InfoEd) for routing that worked flawlessly; there is too much manual determination in the decision-making/establishment around routing. that would be better accomplished with automated, non-manual processes.

2. Improvements:
   1. Automatic route/role determination from backend uploads per Title/Department into "People", NO manual processes. 
   2. Notifications tied to Title/Role, not Unit/Team
   3. The ability to add people to the route without having to stop and restart the route.
   4. The ability to bypass people in the route without having to stop and restart the route.
   5. Recurring reminders (notifications) sent to approve the route, not just one and done.
   6. Ability to see/confirm that notifications are sent out, see that the system is working
3. The complication in our structure seems to be Chair/Dean/Business Officer, particularly the Chair, which again is built from/determined by 2 separate variables
4. The challenges of multiple PIs from different departments and maybe different colleges is:
   1. Manual processes demand a TON of upkeep. If a Chair or Dean changes and we are not aware, it is revealed during the route. The route may have passed through handfuls of people before we find that out. In the current setup, we have to manually stop the route, change the user settings, and start the route again. I have many many routes that "die" this way as we are unwilling to have those handfuls of people re-approve a route. Getting routing approved is a challenge to begin with.
   2. The inability to skip or add a user to the route also plays into the issue described above.
   3. The MANUAL Research Team, Team, and Unit setup is not conducive to the successful routing and notification of the setup as we have it. It is inherently limiting.
   4. Recurring reminder to approve emails sent out, one email is easy to miss. We are constantly having to reach out to users to cajole them to approve the route. 
   5. A popup or user tip reminder that appears when a PI certifies the project-based COI, that they have to hang in and ALSO approve the route. They do one and think they're done. 
   6. REMOVE repeating approvals when a Chair is in that role for several of the Key Personnel and has to approve 3/4 times. Being able to bypass will help this issue.
   7. In-app reminders to "pester" people to approve routes. 

My biggest wish is that routing was intelligently generated based on credentials (title/department) that are fed into the system from the backend and not dependent on manual processes. That and flexibility with the route once it has started.

Please let me know if you have any questions or more information.

Thanks Chelsea,

Karie

Hey Cayuse Community,

As we gear up for even more exciting updates, we want YOUR input! We believe in creating software that truly meets your needs, and your feedback is crucial.

Our planned enhancements are:

• Incorporating And/Or logic to support more complex workflows
• Supporting multi-level reviews based on your institutional unit hierarchy

We want to give you more power over your workflows so that routing becomes even smarter.  These enhancements will be coming at you in 2024.

Our team has a few questions that we'd love for you to answer:

1. Tell us about your most common routing scenario.
   1. How well does Sponsored Projects 4.0 support this scenario?
2. What improvements would make your routing tasks easier?
3. Can you share specific examples of your organization's unit hierarchy that you would like to incorporate into the routing process?
4. What challenges do you face in managing routing for projects that involve multiple units?

Feel free to share your thoughts, experiences, or any specific use cases you have in mind.  Dream big!  What do you wish you could do with routing that you cannot do now?  Your feedback will directly shape the future of this product.

Comment below with your insights, and let's make Sponsored Projects even better together.

Best,

------------------------------
Chelsea Phelan
Product Manager
Cayuse
------------------------------