Salesforce di Claude bisa menulis ke CRM—batasi izin sebelum beta dibuka

Salesforce in Claude masih tersedia bagi pelanggan pilot terpilih, dengan beta terbuka yang direncanakan mulai September 2026. Sebelum akses diperluas, admin perlu memetakan hak baca dan tulis di Salesforce, menguji tindakan dengan akun berizin minimum, serta mewajibkan persetujuan manusia untuk perubahan berisiko.

Pembatasan itu penting karena plugin bukan hanya membaca data: Salesforce menyebutnya dapat memperbarui record dan menjalankan alur kerja. Menurut halaman produk Claudeforce, setiap jawaban dan tindakan melewati izin serta aturan bisnis Salesforce yang sudah ada; Claude hanya melihat dan melakukan hal yang diizinkan bagi pengguna terkait.

1. Petakan objek, field, dan efek perubahan

Mulailah dari tindakan yang benar-benar diperlukan, bukan dari profil pengguna yang paling luas. Buat matriks yang menghubungkan setiap kelompok pilot dengan objek, field, jenis akses, batas record, dan proses otomatis yang mungkin dipicu.

Untuk persiapan rapat, misalnya, akses baca ke Account, Contact, Opportunity, dan aktivitas mungkin sudah cukup. Pemutakhiran pipeline memerlukan keputusan terpisah tentang siapa yang boleh mengubah Stage, Amount, Close Date, Next Step, owner, atau field kustom.

• Daftar objek standar dan kustom yang dibutuhkan setiap skenario.
• Pisahkan hak membaca, membuat, memperbarui, dan menghapus record.
• Tandai field sensitif, termasuk data pribadi, nilai kontrak, diskon, margin, dan catatan internal.
• Catat pembatasan record dari sharing rule, role hierarchy, territory, kepemilikan, atau aturan lain yang digunakan organisasi.
• Identifikasi perubahan yang memicu Flow, Apex, approval process, notifikasi, webhook, atau integrasi lanjutan.

Hasil inventarisasi seharusnya berupa izin minimum untuk setiap skenario. Klaim bahwa plugin memakai model izin lama bukan alasan untuk melewatkan peninjauan: jika akses pengguna sudah terlalu luas, Claude dapat bekerja dalam batas yang sama luasnya.

2. Aktifkan baca sebelum tulis

Mulai pilot dengan skenario baca seperti ringkasan akun, riwayat aktivitas, dan tinjauan pipeline. Setelah batas field dan record terbukti sesuai untuk setiap persona, tambahkan akses tulis secara bertahap hanya pada field yang memiliki kebutuhan bisnis jelas.

Pengumuman Salesforce dan Anthropic menjelaskan bahwa admin menghubungkan layanan satu kali, autentikasi dan izin dikelola terpusat, lalu tindakan dirutekan melalui Salesforce agar aturan bisnis diterapkan. Koneksi terpusat tersebut tidak menggantikan kebutuhan untuk menilai akses masing-masing pengguna.

Gunakan Permission Set atau Permission Set Group khusus agar akses pilot mudah dibedakan dan dicabut. Jangan menambahkan Modify All Data, View All Data, hak penghapusan, atau izin administratif hanya untuk mengatasi kegagalan tindakan; periksa dahulu akses objek, field, record, serta dependensi otomatisasinya.

3. Batasi jalur autentikasi

Sebelum onboarding, minta detail tenant yang pasti tentang aplikasi autentikasi, scope OAuth, persetujuan admin, masa berlaku token, dan cara mencabut sesi. Materi publik produk belum merinci apakah setiap tenant akan menerima kontrol Connected App yang sama, sehingga jangan menganggap mekanisme tertentu tersedia sebelum konfigurasi beta dapat diperiksa.

Jika integrasi muncul sebagai Connected App, pilih akses yang disetujui admin dan berikan hanya melalui profile atau Permission Set khusus pilot. Panduan kebijakan OAuth Salesforce membedakan otorisasi mandiri oleh semua pengguna dari akses pengguna yang dipraotorisasi admin, menjelaskan pencabutan token, serta memperingatkan bahwa izin Use Any API Client dapat melewati pembatasan aplikasi tersebut.

Gunakan pengguna pilot bernama, bukan seluruh departemen. Tinjau pula akun administrator, profile lama, Permission Set tambahan, dan jalur API lain yang dapat memperluas akses di luar matriks pilot.

4. Uji dengan persona yang boleh dan harus ditolak

Gunakan sandbox yang metadata dan otomatisasinya cukup mewakili produksi. Siapkan setidaknya dua persona: pengguna yang berwenang melakukan tindakan dan pengguna yang harus ditolak. Pengujian hanya dengan System Administrator tidak membuktikan bahwa pembatasan untuk pengguna biasa bekerja.

1. Pastikan pengguna berizin dapat membaca record yang memang berada dalam cakupannya.
2. Coba membaca record, objek, atau field di luar wilayah dan kewenangannya.
3. Perbarui satu field yang diizinkan, lalu cocokkan record sasaran, nilai lama, nilai baru, dan hasil akhirnya.
4. Coba mengubah field sensitif atau hanya-baca dan pastikan tindakan gagal.
5. Masukkan nilai yang melanggar validation rule atau persyaratan field.
6. Periksa efek lanjutan pada Flow, Apex, approval process, email, task, webhook, dan sistem terintegrasi.

Gunakan data sintetis atau tersamarkan. Simpan identitas pengguna, permintaan, record sasaran, tindakan yang diusulkan, hasil, alasan penolakan, dan otomatisasi yang terpicu. Skenario dinyatakan lolos hanya jika tindakan sah berhasil dan tindakan di luar kewenangan gagal secara konsisten.

5. Tempatkan persetujuan manusia sebelum dampak berisiko

Salesforce menyatakan admin dapat mengendalikan tingkat otonomi untuk tindakan tulis, termasuk apakah Claude perlu meminta konfirmasi sebelum mengirim email eksternal. Gunakan kontrol tersebut berdasarkan dampak: pembacaan yang sudah dibatasi mungkin tidak memerlukan konfirmasi tambahan, sedangkan perubahan yang menyangkut pelanggan, uang, komitmen komersial, atau banyak record perlu berhenti sebelum eksekusi.

• Minta persetujuan sebelum komunikasi eksternal dikirim.
• Konfirmasikan perubahan Stage, Amount, Close Date, diskon, owner, dan status kontrak.
• Nonaktifkan penghapusan, merge record, dan perubahan massal selama pilot.
• Tampilkan record, field, nilai lama, nilai baru, serta efek otomatisasi yang diketahui sebelum persetujuan.
• Gunakan approval process Salesforce jika keputusan sudah memiliki pemberi persetujuan formal.

Dalam contoh bersyarat, permintaan “bersihkan semua peluang yang stagnan” seharusnya menghasilkan daftar kandidat dan usulan perubahan terlebih dahulu. Pemilik pipeline kemudian menyetujui record serta field yang boleh diubah; perintah awal tidak langsung menjadi pembaruan massal.

6. Tetapkan bukti tindakan dan prosedur pencabutan

Sebelum aktivasi, tentukan log mana yang akan menjadi bukti, siapa yang meninjaunya, dan bagaimana satu tindakan ditelusuri kembali ke pengguna serta record. Pantau penolakan autentikasi, percobaan membaca field sensitif, pembaruan tak biasa, dan pola tindakan massal. Jangan mengandalkan percakapan Claude sebagai satu-satunya catatan jika perubahan juga memicu proses di Salesforce atau sistem lain.

Rencana pencabutan perlu menyebut langkah dan pemiliknya: hapus assignment Permission Set, blokir akses aplikasi yang digunakan, cabut token atau sesi, nonaktifkan akun bila perlu, lalu periksa record serta otomatisasi yang telah berjalan. Latih prosedur itu dengan akun uji agar tim mengetahui apakah pencabutan menghentikan akses baru tanpa menghilangkan bukti audit yang dibutuhkan.

Perluasan dari pilot layak dilakukan setelah pemilik data menyetujui matriks izin, uji negatif berhasil, persetujuan manusia menghentikan tindakan berisiko, dan akses dapat dicabut sesuai prosedur. Dengan urutan ini, kemampuan menulis ke CRM tetap mengikuti batas yang sengaja ditetapkan, bukan sekadar izin lama yang kebetulan masih aktif.

Baca juga:

• Memori Claude kini menyatu dengan Cowork—dan aktif secara bawaan
• Glean membuat agen AI bekerja tanpa prompt—kontrol izin menjadi penentu
• OpenAI mengakui peringatan terlewat sebelum model menembus Hugging Face