Switching a Client to a New Quickbase Developer

Knowledge Base

Knowledge Base

Quickbase Knowledge Center

Roles & Permissions

Switching a Client to a New Quickbase Developer | INTERMEDIATE

May 17, 2024

You’ll eventually work with a new client who has existing projects in Quickbase. That’s the nature of development. Regardless, you should follow best practices to transition the client from the current developer to the new one.

Sometimes, the existing developer still works with the client and can help expedite the process, removing obstacles that would negatively impact new Quickbase users. Other times, you’ll need to walk your client through the process of finding the relevant items to ensure you can continue your work with minimal delays.

Background: Architecture and Logic

You need to understand the architecture and logic of the process before making any changes to a new client’s existing Quickbase applications.

When a client retires a developer, you’ll need to transfer ownership of crucial elements to prevent delays and code issues that could render the application unusable. These include:

Pipelines
Webhooks
Notifications
User Tokens
Code Pages
Table Syncs

Once you address these transfers, you can focus on "nice-to-have" elements. These items will provide insight into the client's development status and highlight existing issues:

Technical Documentation
User Guides
Defect Lists
Manual Processes
Recent and Upcoming Changes
Key Stakeholders
Knowledge Transfers

Note: These may or may not be readily available from the departing developer.

You’ll ensure a smooth transition for the Quickbase application to the new developer by addressing these aspects of the project. This knowledge-base article will walk you through that process.

Getting Started With the Client Transfer: Six Levels of Access

The transition process consists of multiple levels of transferring. The client can provide three levels of access and three additional access levels to be aware of. You’ll need to consider these elements during the transfer process.

The six levels of access are:

Realm Access
Account Level Access
Application Level Access
Table Level Access
Record Level Access
Field Level Access

Depending on the client's needs, they can grant the consultant access at the realm, account, or application level. Ideally, the only access needed is the full account level access.

1. Realm-Level Access:

This is the highest level of access control in Quickbase. Realm-level access controls apply to the entire Quickbase realm (i.e., the entire account).

Users with realm-level access can manage account-wide settings, users, roles, and permissions. They can create, delete, and manage applications within the realm.

Typically, the client will not need to provide Realm Access to the consultant. However, access can provide useful insight into the transfer items over to the user like reviewing pipelines and webhooks.

2. Account-Level Access:

Technically this is not a separate level of access. Still, specific users with administrative roles may manage account-wide settings and privileges. Account administrators can manage billing, subscription plans, and other account-related settings.

Note: Consultants do not necessarily need access to billing and subscription for development.

3. Application-Level Access:

Within Quickbase, applications serve as containers for organizing and managing data. Clients may grant users access to specific applications based on their roles and permissions. Application-level access controls include the ability to create, modify, and delete records within the application.

4. Table-Level Access:

In Quickbase, applications are composed of tables that hold specific types of data. Access to individual tables within an application can be controlled separately, and users may have various levels of access to different tables within the same application.

5. Record-Level Access:

Quickbase allows for fine-grained control over who can view, edit, or delete individual records within a table. You can base record-level access on criteria such as field values or user roles. Users may have various levels of access to different records within the same table.

6. Field-Level Access:

Quickbase also supports access control to specific fields within a table. You can restrict users from viewing or editing certain fields based on their roles or permissions. Field-level access control helps enforce data privacy and security policies.

App Transfer Process:

You can find the app transfer under the app settings → app properties and under the manager's name. The user can choose to transfer the application to the person who needs control. The intended user will receive a notification and control over the new application once this is done.

With access granted at the application level, the user can transfer the needed pieces (including webhooks, pipelines, emails, and table syncs.)

Note: These items will continue to work until you remove the owner from the application.

Pipelines Transfer Process:

Pipeline ownership happens at the administrative level. You must grant users permission to access pipelines.

Previous users should refresh the schema and Fix any issues that occur.
Export the pipeline as a YAML.

The new user should create a new pipeline to capture the account slug

Importing the Pipeline consists of selecting the Import pipeline on the Pipeline’s screen and then uploading a YAML File. If any issues exist in the uploaded YAML File, the import will not work. If a correct YAML has been downloaded from Quickbase and then re-uploaded, this tool will correctly identify the existing name and tags associated with the pipeline so one does not need to rename it.

Once completed, you should run the process of turning off and turning on the new pipeline in a meeting in case any issues arise.

Note: Pipelines are user-based, so Realm access may be necessary to view all pipelines

Documentation of pipelines is helpful for coordinating transition efforts. Additionally, it can serve as a general guide to anyone using the application.

Utilizing another table for storing the pipelines YAML and providing details that describe the process flow is useful for maintaining pipelines because it creates a backup in case there are issues with Quickbase and creates version control (this does not currently doesn’t exist inside the Pipeline page.)

Some pipelines may need to call a webhook or another application. To do so, the user would need to update the alias/user token and have sufficient permission control to run the pipeline.

Webhooks Transfer Process:

∗To be deprecated by Quickbase by End of 2024∗

Webhooks are like pipelines in the sense that they need to have an updated alias or user token to work. Once the new token is in place, then ownership and has been updated in the webhook code or the pipeline callable webhook code, then it has been transferred to the new user. The user token can be found or generated here.

Connected Tables/Sync

You may transfer tables connected to another application. This is under → “Settings” → “Quickbase Connection”→ “Use Different Connection”.

It will show the existing table owner and require the new user to have a table connection in place before connecting to their ownership.

This is set up in “My Preferences” and under → “My Connections” to see if a connection exists. (If not, the user must set up a user token.)

Next, it is advisable to refresh the table to see if any issues exist when using the new connection.

Items to Consider When Transitioning Quickbase Access:

Technical Documentation:

If technical documentation exists or you can request it, then it would be helpful to have. This technical documentation can be from a user's viewpoint and/or administrative level.

At the administrative level, the details should include:

Pipelines
Webhooks
Permissions
Dashboards
Notifications
Access
How the System Works
Logical Processes
Descriptions of Tables
Use Cases
Important Formula Queries (if they exist)

At the user level, it could include:

How to navigate the system
What process to follow and who to contact if issues arise

Note: Documentation can also be created through recorded sessions.

Notification Access:

You can transfer notifications via the notification setting at the bottom of the screen. This will change ownership. That is all that is required.

Note: The notifications will continue to work without doing this. But, it is a best practice.

User Guides:

This falls under technical documentation, but you should request and review any user guides that exist before the transition process.

Defect List:

A defect list can consist of outstanding items or issues at the time of transition. These items can be considered bugs (or bugs that result from incorrectly using a process).

Manual Processes:

Any existing manual processes used by the user or business process should be documented as part of the documentation.

Note: You can identify these by asking yourself, ‘What does the user do on a typical day inside Quickbase?’

List of Recent Changes:

This is a list of developments that have happened over the course of a specific period.

Note: The standard time frame for tracking developmental changes is 3 months.

Upcoming/Future Expected Changes:

You should document any future development changes or expected app development that is needed or to be developed by the new user.

Explanation of Processes/Knowledge Transfers:

Asking the existing team for knowledge transfers is incredibly useful. These should be recorded with notes taken at the meetings. You should request additional meetings, as necessary.

Note: Meetings should consider general, in-depth, and outstanding questions.

Reverse Knowledge Transfers:

Once the general knowledge transfer is complete, the new users should recite the new information back to the original owners to make sure the information transfer was successful and no clarifying questions remain.

Key Stakeholders and Points of Contact:

You should document stakeholders and points of contact (most notably super users and billing account managers). Should the user need additional needs for Quickbase, these users could provide access.

Summary: Transitioning Quickbase Access to New Developers

In this how-to guide for transferring Quickbase access to new users, you learned the step-by-step process for transferring different access levels and functionalities.

Starting with realm-level access (which governs entire account settings) you can navigate through account-level, application-level, table-level, record-level, and field-level access controls.

The guide emphasizes the importance of understanding and managing each level effectively. We have provided detailed instructions for transferring applications, pipelines, webhooks, and connected tables/syncs, ensuring a smooth transition between users or teams.

Additionally, the article highlights key considerations such as technical documentation, user guides, defect lists, and knowledge transfer sessions to facilitate a successful handover process.

By following these guidelines, users can confidently manage access and functionalities within Quickbase while transitioning between stakeholders or teams.

For more guides on Quickbase, visit our knowledge base.