Hello! A lot of the docs I create typically involve a hidden “backstage” section, where all the base tables live, and then various filtered views on the visible pages. This works great, except I’ve noticed one downside:
Anytime users get emails that reference rows in a doc (getting tagged in comments or using the email-a-page functionality), the auto-generated links in the email always link them to the base tables in backstage.
I don’t want to confuse users by showing them the backstage area, but sometimes there could be sensitive information that I definitely don’t want them to see.
How are other doc makers dealing with this problem? Is there a way to set the Coda email links to go to a view instead of the base table?
I think another solution would be to treat the base table like a view (filtered and on visible pages), and create an unfiltered view in the backstage. The links would no longer go to the backstage. Are there any concerns with filtering the base table?
But I would still stoically stick to the principle of putting base tables into backstage and only showing views elsewhere. I would try to avoid links in the emails (i.e. I wouldn’t include raw Lookup columns in the views that get emailed but rather bring over the Text columns) or construct those links manually myself (through a dedicated Hyperlink() column) and hope that one day Coda adds the capability to select the default view to display links to, rather than give up on the principle.
Thanks for the response @Paul_Danyliuk. That makes sense to use hyperlinked text columns to circumvent this issue.
Stoicism aside, would there be any fundamental issues with treating a base table as a filtered view? It may add a bit more risk that the table could accidentally be deleted, but I think that would be the only downside? Docs that rely heavily on users commenting on rows—thus getting email notifications anytime there is comment activity—would be critical to prevent them from going backstage when they click on the “View Comment” link in the email.
I’m excited to to engage more with this community—thanks!
There’s one major difference between a base table and a view:
When you set a filter on a base table and then refer to the table in a formula, it returns all rows.
I.e. the filter on a base table is applied for display only.
When you set a filter on a view and then refer to the view in a formula, it returns only visible rows, i.e. those that passed through the filter.
So technically:
a table is stored in a doc file as display metadata + actual row data
a view is stored in a doc as display metadata + a list of row IDs that are selected for display in that view. Unless it’s volatile and based on User()/Today()/Now() — then the list is calculated every time upon doc load.
Not sure if this affects the workflow much but this is a detail to keep in mind.
We’ve definitely seen that this is a need and we notice it with docs we use internally as well. There is a formula that gets us most of the way to a solution and we might dig into it more after some of our other projects finish up.
OpenRow(thisRow,[My Table View])
You’ll see that the formula builder help mentions “view or layout” for the second parameter, but we don’t have the ability to designate a layout yet. If you’re able to pick a view that’s outside of your hidden main tables section though, this might work for you.
I am dealing with this same issue where a team member receives an email notification but when they click the link to the Coda doc (from within the body of the email notification) the user is taken to the “base table” and not where I would prefer they be taken which is to the View of the Base table. Curious if you could elaborate on your suggestion to make dedicated Hyperlink()s. Thank you!
@BenLee I know this thread is from a few years back. I am curious if you are aware of a way for team members that receive an email notification after they have been “@” in a doc … if the team member can go to a view of a table instead of being sent to the “base table?” Thank you in advance for any help you can provide.