Welcome to the Smartsheet Forum Archives
The posts in this forum are no longer monitored for accuracy and their content may no longer be current. If there's a discussion here that interests you and you'd like to find (or create) a more current version, please Visit the Current Forums.
Update Request Enhancement Wish List
I have been researching how to use update requests to send automatic messages to different users within a database concept I am developing; however, I have run into a few gaps, so here is my update request wish list!
1. Send recurring update requests based on a date column.
2. Add additional criteria options similar to what is available when creating a reminder. (e.g. 'x' days before date, if box is not checked, etc.)
3. Send recurring update requests to the contact assigned to that row.
4. Resend pending update requests.
5. Add option to cancel request (without deleting) in order to retain update request history.
I love the update request feature and the fact that it allows me to get down to a row specific level so that users are not accessing any other information besides what is specified. My wish list is somewhat long but these enhancements would enable us to allow more people to manage the data that belongs to them in a larger sheet with more sensitive data without having to manually manage it on the back end by creating each update request individually. More automation would be a dream come true!
I'd also love to know if there are any work arounds to the issues I've run into.
Thanks for taking the time to provide your feedback. I'll send your requests to our Product team for further review.
To make sure that I understand #1 on your list, how would you want this to work? You can only have one date in a date column, so how would you like to have an update request recur based on that single date?
Would you want send every x days/weeks until or after [date column]1? Or some type of conditional logic around?
Or would you want the date in the date column to change on a recurring basis as a recurring update request is sent?
Or are you picturing something else entirely?
Hello! Thank you for the response!
Regarding #1: I guess it wouldn't necessarily be recurring persay, however, if I change the date in the column, I would like the update request to reflect the modified date and renew in a sense along with the conditional logic.
The scenario we would like to use an enhanced update request feature involves expiration dates. So as expiration dates are updated (through an update request) based on renewals, the current update request would essentially renew following the date modification and send the same update request on a new date in the future based on the specific conditional logic set for it (a combination of X months, weeks, and days before/after expiration).
Thanks for taking the extra time to write this out! This helps our Product team immensely when developing new features
I would also like additional functionality on the update request. The ability to send based on assign to column would be nice. I would also like to see the ability to stop sending the request once a certian criteria has been met - such as %complete = 100.
KPKC had a great list. I'll add some more UR feature NEEDS:
Let's say: UR=question, and UC=answer
1. Have the title of the Update Request UR and Update Confirmation UC emails be the same, just like an email title stays the same in a reply. (currently they are different, and I cannot group the request to the confirmation using any Outlook rules)
2. Include the text of the UR somewhere within the UC, just like an email reply has the original text embedded. I send out dozens of requests per week, sometimes on very similar items. It is hard for me to know if the answer is complete because the question is no-where in sight.
3. Setting that will re-send the UR until it is completed by the assignee. (keep reminding the person of the request until it is done)
4. Allow for people to close a UR from the UR interface window. Forcing them to use the email every time is not optimal, and if they lose the email then the UR is open forever.
5. Just like the web-form, allow for mandatory fields in the UR. Particularly a mandatory "reason" field if the assignee decides to close it without making any changes.
6. Setting that will allow for the Requestor to enforce approval of the update confirmation before it is applied. THIS WOULD ABSOLUTLEY BE HUGE.
I spend an average of 7-12 hours a week following up with UR. Not only because people don't answer them, but also because the Features requested above show you that trying to link the question to the answer, and then ensure that the change in the sheet matches the question is a cumbersome, tiring, and exceedingly frustrating process. I could basically live without items 1,2,5 if I just had #6 here.
-I have so many users who are ESL, and I may write out a list with question1, question2, question3- and they will send back and update with ansirr98z. In this case, they've closed the request, but it's not an actual solution - it's just ticking a checkbox. If the requestor can have a checkbox option to require validation, that would eliminate a MASSIVE amount of the work I do following up with URs.
7. Create a unique index number for reach UR. Just good housekeeping.
8. Just like you have a note in the sheets that a cell was changed by cell-link, it would be good to have a note in the cells to indicate that a change was made by UR - and maybe reference the index from item 7 above here.
In response to Brad's list:
1. While you are making the email titles the same, make them configurable.
One PMO group uses workspaces as templates and the underlying sheets do not change names - Schedule vs Bob's Kitchen Schedule
I've made the case of changing the sheet names, but have met resistance.
2. Yes please.
3. and automate the counter - "Second request", "Third Request", etc...
4. Yes please.
5. Yes please.
6. ESL = english as second language. (had to look it up).
Yes. I can see several use cases beyond what Brad describes.
7. Brad - where would this be displayed?
8. Yes please
Hi Brad & Craig—
I've got your votes down for these Update Request and Update Confirmation enhancements, but I have the same question as Craig on #7.
Would you like to see this unique ID in the subject or body of the update request and update confirmation? Or if it's just for housekeeping, would using an auto-number column in your sheet do the trick? Or would you only want to see them in the cell history?
It would have to be visible somewhere. IF it is in the subject line, that makes it easier to filter/group. But, you'd also have to consider where to integrate it into the rest of the SW.
I have auto-number columns in my sheets to perform this indexing feature, and I manually type it into my email subject lines, but the UR omits system columns by default (which is weird, because if I click on SendRow it includes the system columns by default) ??BUG??
That makes sense.
The behavior is expected, since auto-number/system columns are uniquely always read only. Update Requests are designed to deliver information that people can change, but will make cells with formulas (including dependency enabled columns) read-only.
I think that's the crux of it: the ability to include grid data (including system column data) in the subject and the ability to include auto-number/system columns by default.
Or at LEAST a configurable default setting for Update Requests.
Don't get hung up on that one. That's the least important one. Get to the other ones first.
#6 would cause me the greatest immediate benefit, followed by 5 & 1, and then the rest.