Rows being removed

Robin Sherwood

Chris, Brad et al, 

Thank you for providing insight into your particular use cases. Smartsheet has been designed around the concept of flexibility and free collaboration. These concepts are embedded in all of our features and this approach has allowed millions of people to use Smartsheet for thousands of different use cases. The ability for an editor, even a free collaborator, to make a change to a sheet given the editor permission is a deliberate feature of the platform, it is working exactly as designed. That does not mean that there are not valid use cases where more restrictive control is required, and this is exactly why features like update requests were created. We understand this thread is asking for an enhancement to the editor role with more restrictive permissions. A restricted editor is a new feature we have considered but has not yet been prioritized. 

For this restricted editor to work, could a user delete cell content? How is deleting a row different than overwriting an existing row? Would restricting delete to "assigned rows" solve the need? What if I accidentally add rows? can I delete as long as I haven't saved yet? What would be really helpful would be to know what you are using these sheets for, what is the actual process and why users are accidentally deleting data in the first place. 

Thanks!

Robin

Simon Hill

Robin, many thanks for responding - much appreciated. You ask some very good questions, I will do my best to answer from my perspective:

I typically use Smartsheet to collaborate on projects; gathering requirements, tracking feedback, project plans etc.. When you spend several weeks or months building up requirements or logging feedback you want to avoid somebody accidentally deleting this data. To answer your specific questions:

Could a user delete cell content? yes - but a restricted user should not be able to highlight a number of cells and press delete. An additional protection to allow making columns required would be helpful - this would ensure that required columns can not be simply blanked out.

How is deleting a row different to overwriting an existing row? Just that it is easier to delete rows than it is to overwrite them so can easily be done by accident. 

Would restricting delete to "Assigned Rows" solve the need? I am assuming "Assigned rows" would be a new feature to allocate rows to user - for me this would not be the ideal solution

What if I accidentally add rows? Can I delete as long as I haven't saved yet? Yes - perhaps the easiest way to do this would be to allow deletion of rows you have created. An alternative solution - on sheets where deletion has been protected, deletion would archive the rows and the sheet owner would be notified that rows have been archived and would have the option of reinstating them.

The main thing we are trying to protect against is a user highlighting several rows and deleting them by mistake - very easy to do by hitting the delete key and there is no way back. 

I hope this helps

 

 

 

Ann Florkowski

Totally agree Simon, thank you for posting a detailed response. It's too easy to delete information without realizing it. In my case users have deleted all cell data in a column - they highlight a column header, hit the delete key and move along without knowing they did anything. 

Without going into admin vs editor vs restricted editor roles - if any user does this, maybe display a confirmation dialog box. Something to the effect - Are you sure you want to delete? I've seen this done on a competitor platform.

Chris Gambrell

Thanks Simon, good responses to those clarifying questions.

Robin, Simon's answers should suffice for the clarification you're looking for.

Brad Jones

Use cases:

We/I the administrators create a sheet and workspace for the users to work in.  We want to keep the workspaces and sheets uniform so that 'floating' users can go from project to project and not need to learn a new layout for reporting/editing updates for the project.

For most of our projects, the tasks/rows are fairly well defined and monitored by our QA group.  One group manages the most of the activities while the 'primary users' do the work of filling in the time, notes, and attachments related to the activities.  We are in a medical industry, and the idea that someone could arbitrarily delete evidence that a critical test was completed is completely unacceptable.

If any cell is locked on the row, we don't want editors to be able to delete said row.

 

Processes:

Design is ALWAYS stronger than process.  I wrote a user guide for my users that explicitly states in unpleasantly large text to "NEVER DELETE ROWS".  Additionally, I have created many training videos for the users in our company that repeatedly echo the same refrain.  But, as others have pointed out it is far to easy for a user to delete a row or column content without even knowing it.  (In the Row Menu the Delete Row option is right next to the Insert Row option)

 

Questions:

?Can a restricted editor delete cell contents?

YES:  If they can edit, please let them change any data within an unlocked cell - just as it is now.  The cell history will keep a record of the changes.

?How is deleting a row different from overwriting the data?

TRACEABILITY:  When you delete a row, all of the cell history disappears never to return again.  If they simply overwrite the contents then there is still a record of what the old values were.

?Would restricting delete to assigned rows be a solution?

NO:  This won't work for our implementation. We don't want anyone to delete rows unless they have privileges above editor.  With the existence of filters and reports, the need to delete rows for readability is greatly reduced.

?If I accidentally insert a row, can I delete it before I save?

MAYBE:  Because we want uniformity and traceability, we want to avoid any case in which a user can delete a row.  This could be an OK implementation.

 

Wishlist:

1 - QUICK WIN - Create a prompt for users that asks "are you sure you want to delete ..." that will at least highlight when the users are about to delete a row.

2 - We already have two user categories for editor (can't share, can share).  Make another category for Editor Restricted so that they can edit/modify any unlocked cell but not delete any row/cell/column that is, or contains, a locked cell.

3 - Develop a way for us to do a mass user modification so that we can retrofit existing "Editor can not share" permissions with "Editor Restricted" permission levels.  This will be key to getting our system working the way we need it without days of work on the part of the sheet owner/admins.

4 - (slightly off topic, but strongly related)  Develop a true backup solution that will allow users to FULLY reinstate a sheet from a backup copy should something go wrong.  Currently the only backup solutions are woefully insufficient as they don't mark the backup attachments with the row they are attached to, and doing a manual restore in the current system does not maintain cell history.

 

Thanks Smartsheet for reading and replying to this thread.  MANY of us in the user community are very upset that we have no solution for this.  While the current functionality may be fully compliant with the software design - that does not make it compliant with the user base needs.

PLEASE PLEASE PLEASE put this into the priority development queue!  This is going on three years as a top ten problem for the users but it has been neglected for the sake of more cross-platform integration fluff and UI updates that just make the users PO'd.  It's not a glamorous project for the developers, but it is a critical one for us users.

Many of us are willing and able to participate in focus groups to assist in this objective - but until you actually prioritize this and start development we are stuck moaning in the forums instead of constructively helping you make this a reality.

Nwood1982

I'm going to also add my +1 to the request for a new user type "Editor - cannot share or delete" (or similar).

If instead there is a way to lock down rows to Admin, Owner and a person/Editor listed in a Contact List cell (Assigned staffmember), that would be great to know about as well.

As to your questions Robin, I'm happy to help:

For this restricted editor to work, could a user delete cell content? All but locked cells, yes

How is deleting a row different than overwriting an existing row? Row deletion leaves you with nothing, being able to lock out cells from a restricted editor would at least leave you knowing what needs rebuilt (from still having key information in the locked cell(s)).

Would restricting delete to "assigned rows" solve the need? MOSTLY – See data locking above

What if I accidentally add rows? Can I delete as long as I haven't saved yet? I don't see any reason why not, but easier to disallow- slight burden on the admins to clean up, but certainly less of a burden than having to rebuild the assiduously collected data in case of accidental deletions.

What would be really helpful would be to know what you are using these sheets for, what is the actual process and why users are accidentally deleting data in the first place. 

In this instance, we track a time-intensive onboarding process (hiring doctors) to make sure no pieces get missed. It’s a collaborative process, with each row being a provider and being assigned to one person who puts in data to each of the cells showing what or when different things have been requested. Losing data can lead to negative outcomes for patients as doctors may not have the tools they need. Automating update requests gets us part of the way there, but it limits when/how often the user can update their work, which slows productivity.

Accidental deletion can be anything from mis-keying something or a sticky shift key (and deleting data from a massive range of cells without realizing it). It is most often from users who are less tech-savvy, but can happen to anyone.

dkalutskiy

We are new to Smartsheets, but the main way we intend to use this product would rely heavily on this function. We intend to build a calendar/task-list where managers and administrators would have ability to maintain a list of deliverables and the rest (users) who would just sign-off on the tasks assigned to them.

 

For this restricted editor to work, could a user delete cell content? Our goal is to give users an edit-only option for specific non-formula cells. We don't want users to add/delete items. Our assumption was, that by locking information-only and formula columns we have accomplished that, but then an "Editor - Cannot Share" tester was able to delete a series of rows with seemingly no way of knowing which rows were deleted and how to restore them. I have attempted to set up an email alert to send administrators details of what was deleted, but apparently it just comes in empty.

 

How is deleting a row different than overwriting an existing row? With majority of the task list columns locked out (except for sign-off options and comments), the user is not currently able to edit important locked formula and identifier columns, but can currently still delete the entire row. We also don't like that we can't seem to be able to receive any notifications about what was deleted.

 

Would restricting delete to "assigned rows" solve the need? No, because just knowing that an item is deleted is insufficient to restore it if that deletion was done in error.

 

What if I accidentally add rows? can I delete as long as I haven't saved yet? We would prefer if the task list was locked from both additions and removals for non-administrators. But if a row was deleted, we would still like to be able to auto-notify an administrator with the details.

 

What would be really helpful would be to know what you are using these sheets for, what is the actual process and why users are accidentally deleting data in the first place. Our main goal is to replace the current calendar/task list tool we have with a product that has email alerts, collaboration options and single sign-on; and we would prefer if the users didn't have the option of deleting important time-sensitive deliverables without manager approval or in error.

Kenyon Bajus

How is deleting a row different than overwriting an existing row? 

Because we have cell history with overwritten data. Deleting an existing row leaves us with nothing!

David Jasven

Hi Travis,

This issue around deleting rows has been around for ages.  Is it ever going to become a reality that this functionality will one day exist?  It seems crazy that with the amount of "pressure" to have this feature come to fruition, that something would not have been done by now.