Hubungkan Supabase untuk memulai email bermerek saat seseorang mendaftar, mengonfirmasi emailnya, mengubah kata sandi, atau diblokir. Skrip penyiapan menambahkan trigger database ke tabel auth.users Anda, dan Brew mengubah setiap perubahan menjadi salah satu dari 12 pemicu otomatisasi.
Supabase Auth tetap bertanggung jawab atas proses masuk, tautan konfirmasi, magic link, dan reset kata sandi. Brew membuat dan mengirim email yang menindaklanjuti perubahan tersebut.
auth.user.signed_in dipicu saat last_sign_in_at berubah. Pembaruan token Supabase juga mengubah kolom itu, sehingga peristiwa ini bisa dipicu berulang kali selama sesi pengguna masih aktif. Peristiwa ini tidak menunjukkan bahwa seseorang kembali setelah lama tidak aktif.
Peristiwa ini juga merupakan peristiwa turunan dengan prioritas terendah. Jika pembaruan yang sama mengonfirmasi email atau mengubah pengguna anonim menjadi akun permanen, Brew menghasilkan peristiwa tersebut, bukan auth.user.signed_in.
Untuk menyapa pengguna yang tidak aktif, tentukan ketidakaktifan di aplikasi Anda berdasarkan data aktivitasnya sendiri. Kirim peristiwa kustom Brew terpisah hanya untuk pengguna yang memenuhi syarat, lalu biarkan otomatisasi berstatus Aktif mengirim email sapaan dari peristiwa tersebut.
Uji kedua jalur: pengguna yang tidak aktif menerima email sapaan; pengguna yang aktif sebelum pemeriksaan tidak menerimanya.
auth.user.created, auth.user.updated, dan auth.user.deleted berasal dari penambahan, pembaruan, dan penghapusan baris di auth.users. Brew menghasilkan peristiwa lainnya dari pembaruan dengan membandingkan baris lama dan baris baru.
Satu pembaruan menghasilkan satu peristiwa. Jika beberapa kolom berubah bersamaan, kecocokan pertama yang berlaku, dengan urutan berikut: email_confirmed, phone_confirmed, upgraded_from_anonymous, email_changed, password_changed, banned, unbanned, invited, signed_in. Pembaruan yang tidak cocok dengan satu pun di antaranya masuk sebagai auth.user.updated.
Brew mendukung 12 jenis peristiwa berikut:
Setiap peristiwa terverifikasi yang memiliki alamat email sungguhan akan membuat atau memperbarui kontak Brew, yang dicocokkan berdasarkan email, baik peristiwa itu dipakai otomatisasi maupun tidak. Jika datanya tersedia, Brew mengisi nama depan, nama belakang, supabase_user_id, supabase_phone, supabase_role, supabase_full_name, supabase_avatar_url, dan supabase_provider.
Beberapa peristiwa juga mengisi field siklus hidup. supabase_account_status berubah menjadi active, invited, banned, atau deleted. supabase_email_verified_at, supabase_phone_verified_at, dan supabase_last_sign_in_at berasal dari peristiwa konfirmasi dan masuk akun yang sesuai.
Gunakan skema payload yang dideklarasikan untuk peristiwa terpilih sebagai acuan merge tag. Setiap peristiwa menyertakan email dan, jika tersedia, firstName, lastName, fullName, displayName, avatarUrl, phone, role, provider, createdAt, lastSignInAt, dan emailConfirmedAt. Nama dan avatar diambil dari raw_user_meta_data, dengan sumber cadangan untuk pendaftaran lewat OAuth. Ketiga stempel waktu tersebut dinyatakan dalam detik Unix.
Peristiwa turunan menambahkan previousValue, newValue, atau keduanya, yang berisi nilai kolom lama dan baru dalam bentuk teks. auth.user.password_changed tidak memiliki keduanya. Field provider berisi metode pendaftaran, seperti email, google, atau github, sehingga Anda dapat mengarahkan alur sambutan berdasarkan cara seseorang mendaftar.
ID pengguna Supabase tidak tersedia sebagai merge tag. Brew menyimpannya di kontak sebagai supabase_user_id untuk keperluan filter dan segmentasi.
Akun Supabase tidak membuktikan adanya persetujuan untuk email pemasaran. Catat persetujuan saat pendaftaran dan periksa sebelum pengiriman promosi.
Tidak. Supabase Auth tetap mengirim tautan konfirmasi, magic link, undangan, dan reset kata sandi melalui penyiapan email miliknya sendiri, seperti SMTP kustom. Brew memulai otomatisasi setelah perubahan tersebut tercatat di auth.users. Supabase menyarankan domain pengirim yang terpisah untuk email autentikasi dan email pemasaran.
Menerima peristiwa dan mengirim email adalah dua langkah terpisah. Pastikan otomatisasi yang cocok berstatus Aktif, lalu periksa filter dan riwayat eksekusinya, kelayakan penerima, serta domain pengirim. Peristiwa untuk pengguna tanpa alamat email, seperti pengguna anonim yang belum menambahkan email, tidak membuat kontak dan tidak memulai otomatisasi.