Issue

Record a request’s review, discussion, and approval in Bytebase.

Custom approval flows require Enterprise. Plans and their linked Issues also exist without this feature; in that case, review requires no human approval.

An Issue is a request for review or approval in Bytebase. It records the request, its approval flow, and reviewers’ discussion and decisions. For a database change, the Issue is linked to the Plan that defines the work. Other Issue types handle requests for roles or temporary database access.

For example, a developer proposes adding a column to an application’s database. The Plan holds the SQL and targets; its Issue records the reviewers, feedback, and approval.

Issue versus Plan

A Plan manages the database change from preparation through deployment. Its Issue manages review and approval. Submitting a Plan for review submits its linked Issue; it does not convert the Plan into an Issue or replace it.

For changes to existing databases, Review on the Plan page displays the Issue. An Issue link opens that same page, so authors and reviewers can see the SQL, discussion, and deployment together.

Create and submit a review request

For a schema or data change in the UI, Create saves the Plan and its linked draft Issue. The author prepares the SQL and checks, then clicks Ready for Review to submit the Issue. Bytebase determines the approval flow from the configured rules.

In the GitOps workflow, pull-request review and CI checks take place before deployment. Release-based Plans have no Bytebase Issue review phase.

Other requests have their own entry points: Create Database opens its Issue workflow directly, while role and temporary-access requests follow database access roles and Access Grants.

Review a database change

Open Review on the Plan. Read the proposed SQL and target databases, then inspect the approval flow to see whose decision is required. Add comments to discuss the change. An eligible reviewer uses Review to approve or reject it.

Approval rules select the reviewer roles and any required sequence. For example, a flow may require a Project Owner’s approval followed by a Workspace Admin’s. Permission to read or comment does not itself grant permission to approve.

If feedback requires changes, the author updates the Plan’s SQL and checks the new automated results and approval state before proceeding.

Understand the approval outcome

• Draft: the request has been saved but not submitted for review.
• Under review: approval is pending; the flow identifies the current reviewer.
• Approved: the required review decisions are complete. Execution has its own status under Deploy.
• No approval required: the configured flow needs no reviewer decision. The UI can show Skipped or Bypassed; read the approval flow and activity to understand why.

In this example, Approval Flow says No approval required, and Activity records that review was skipped and the Rollout created. The Bypassed badge describes that outcome; it does not show a reviewer overriding a requirement.

For submitted UI changes to existing databases, Bytebase automatically creates the Rollout after approval is satisfied and checks finish without errors. Approval alone does not mean the SQL has executed.

See Custom Approval to configure rules, or the UI tutorial to follow a complete change.