Using Table Aliases in the URLs

I think you may need to supply some additional context to make sense of this.

Are you saying you can (1) type this into the address bar or (2) write a formula? If a formula what type of field (URL, Rich Text )?

Also I am confused by (1) the angle brackets and (2) the apparent presence of both the app dbid and table  dbid in the URL. Can you provide a working example linking to a public application?

Type it into the address bar.  Try it!

Here's an example:
https://davidsbakery.quickbase.com/db/bfhqnt2n2/(_DBID_CUSTOMERS)?a=td

• bfhqnt2n2 is my app id
• _DBID_CUSTOMERS is my table alias

I know its weird to have both the app id and the table alias, but consider that the table alias is defined by the original name of the table and that two separate applications can both have the a table with the same table alias.  So the app id is required.

Okay I now see how this works.  There is no formula evaluation involved in using these types of URLs where for instance the value of _DBID_CUSTOMERS is evaluated to the dbid of the Customers table. Rather the raw string "_DBID_CUSTOMERS" is part of the URL path that is aliased and routed to the Customrs table.

I can see where these types of URL might be of some use in making an application portable  when copied in a situation where script was used. But that would largely apply when making API calls. If this style of URL were to ever show up in the address bar or displayed as cover text for a hyperlink it probably will just cause confusion. I think I am going to stick to the practice of parameterizing my scripts with variables prefixed with dbid as they are more readable.

On the other hand if QuickBase uniformly used a URL addressing scheme that included that application dbid and table dbid in all URLs it might provide some nice encapsulation and isolation between applications. For example, such a scheme would  allow a Service Worker to register to the scope of an application rather than the overbroad scope of the entire account or the underbroad scope of an individual table (which is the current situation).

One final comment: How in the world did you discover this feature?

I have seen posts where developers recommend making an application level API_GetSchema to get the mapping of table aliases to dbids.  The URL format I describe would make this call not necessary anymore.

As you said, I think the format form is usable when making copies of an application.  In some cases, it is important to have a separate application for development from production.  Assuming the table aliases match between DEV and PROD, this url format provides one less change to me made during the release to production.  If a developer is also meticulous enough to keep the field IDs the same, the only change required for the release is simply to change the app DBID for these urls.

For formulas, you can simply use the table alias in place of the table DBID, so this URL format would not be required.

I don't see any limitations of using this URL format, however it does make it important to be descriptive when first naming the table.  Since the table alias is generated based on the first name of the table and cannot be changed, (even by support, I checked), it is important to not have your table alias be _DBID_TABLE_1.

To your final comment, watch the network traffic when visiting the MyQB page.  There is some request made to https://intuitcorp.quickbase.com/db/bh28u4xv2/(_DBID_PUBLISHED) in all accounts.  The call has to do with the Quickbase Marketplace.