BigQuery Sync

Overview

This domain consists of a single table, bigquery_sync_config, which stores the settings the platform uses to pull customer summary data from the customer's own Google BigQuery on a schedule and map the results onto LINE friend attributes.

The typical use case is a customer who already runs a data warehouse and computes figures such as lifetime spend or membership grade in BigQuery, then wants LINE Management to use those numbers for segmentation and messaging.

Core Data Structure

bigquery_sync_config

Group	Columns	Notes
Connection	project_id, summary_table, credentials	credentials holds the service account JSON as TEXT
Mapping	user_id_column, field_mappings	user_id_column defaults to user_id; field_mappings is JSONB mapping columns onto attributes
Schedule	sync_cron, enabled	Defaults to 0 6 * * *, i.e. daily at 06:00
Last run	last_sync_at, last_sync_result	The most recent outcome, stored as JSONB for display in the settings screen

The unique constraint (organization_id, line_oa_id), named uq_bigquery_sync_config_org_lineoa, enforces one sync configuration per channel. The table uses soft deletes via deleted_date.

Related Files

• prisma/schema.prisma:1560 — the BigquerySyncConfig model
• schema-dumps/2026-07-24/schema.sql:1108

Connections to Other Services

• cms-api-go provides the configuration screen, including a button to verify that the credentials and target table actually work.
• worker-go runs the cron defined by sync_cron: it queries BigQuery and updates line_user.custom_attribute according to field_mappings. Those updates fire the attribute_changed trigger as usual, unless app.skip_triggers is set for that run.
• The data lands in LINE Friends, and every key used in the mapping must already be declared in the Attribute Registry.