Salesforce 中文筆記

前言 這個模糊的 error message 可能 在很多不同的場景 出現，本篇側重於 convert lead 時出現的： 可能原因 原因一 也許該 user 沒有對於此 lead record 的編輯權限。 可使用 SOQL 驗證： SELECT HasAllAccess, HasDeleteAccess, HasEditAccess, HasReadAccess, HasTransferAccess, MaxAccessLevel, RecordId  FROM UserRecordAccess  WHERE RecordId = '{record id}'  AND UserId = '{user id}' Workbench Quick Link 原因二 可能是此 lead record 因為 approval process 而被 lock 了。 針對單一 record 的解法： 以 admin 帳號切換到 classic 介面點擊 unlock button 後，再請 user 試一次。 釜底抽薪的解法： 到 approval process 把 action 設為 unlock 參考資料 https://developer.salesforce.com/forums/?id=9062I000000DKN4QAO

可能原因 1. Wrong Object Type 例如在一個 User lookup filed 內嘗試填入一個 Contact Id 2. Record Deleted 嘗試操作的 record 可能已經被刪除了 3. No Permission 操作到的相關 record 可能只有 read only 權限 參考資料 https://developer.salesforce.com/forums/?id=9062I000000DKN4QAO  

情境說明 之前有一篇談到 如何快速用 SOQL 撈出哪些 Profile / Permission Set 有權限對某特定 Object 做 Create/Read/Update/Delete 那篇的主題是針對 object record的 CRUD 在討論。但今天我們有另一個不同的面向要處理：如何大規模地查看或更新各 profile 對於某個 object 的 record type 的存取權限。 這又是一個獨立的設定了。不是 record 層級的設定，也不是 Field-Level Security 的設定。是 Record Type 的設定。 若只是要更動一兩個 profile 的 record type access permission 倒也不難，網頁上滑鼠點一點即可。但如果今天我們需要大模模更動呢？ 例如我們有某一個既有的Opportunity Record Type，想要一次開給所有 Profile 都能有存取權限。或是反過來，想要讓僅一兩個 Profile 擁有存取權限，其它通通都不準看到。 難道我們要一個個點進每一個 Profile 去慢慢檢查、慢慢設定嗎？ 此處提供一個沒那麼辛苦的解法。 解法概念 用 SFDX 下載 Profile and Record Type 的 XML 檔 用 Visual Studio Code 尋找、大量取代 Deploy 回 Salesforce 解法細節     第0步，把Visual Studio Code 和 SFDX 環境設定好。 用 SFDX 下載 Profile and Record Type 的 XML 檔 準備同時包含 Profile 和 RecordType的 XML package.xml <? xml version = "1.0" encoding = "UTF-8" standalone = "yes" ?> < Package xmlns = "http://soap.sforce.com/2006/04/metadata" > < types > < members > * </ members > ...

Summary  If you have granted user an object permission by Permission Set(eg. Read, Edit, etc), when you convert a lookup field to master-detail field on that object,  the object permission in that Permission Set will be removed automatically if the permission set hasn't grant the Master object permission in advance. 經實驗證實，如果你原本藉由 Permission Set 來授予 user某 object 的權限， 當你把這個 object 上的 lookup field 轉換成 master-detail field 時，原本在 permission set 裡的的這個 object permission 會自動被移除。 除非這個 permission set 原本就有包含 master-detail relationship 裡那個 master object 的權限。 實驗步驟 1. 開一個全新的 permission set ，在其中給予 foo object 的 read 、 edit 權限。並給予對於 foo object 各 field 的 read 、 edit 的 Field - Level Security (FLS)。 2. 把 foo object 裡 lookup 到 bar object 的 field ，轉成 master - detail type 3. 檢視剛剛新開的 permission set ，發現剛給的 object permission 都被清空歸零了。但是FLS都還在。 4. 手動再次把 read 、 edit 等權限勾回來，會發現 permission set 會自動新增 bar object ( master object )的 permission 。(也有可能不會發現，因為他是偷偷自動完成的) 補充說明 雖然Permission Set裡面的 object permission 勾勾...

以查詢某個user對 Account 和 Contact 的權限為例： SELECT DurableId,EntityDefinitionId,IsCreatable,IsDeletable,IsEditable,IsReadable,IsUpdatable  FROM UserEntityAccess  WHERE UserId = '<UserId>' AND EntityDefinitionId IN ('Account','Contact') 如果要查的是 Custom Object，則需要先找出該 Object 的 DurableId： SELECT DurableId FROM EntityDefinition where QualifiedApiName = 'CustomObject__c' 得到 DurableId 後，再到 UserEntityAccess 去 Query： SELECT DurableId,EntityDefinitionId,IsCreatable,IsDeletable,IsEditable,IsReadable,IsUpdatable  FROM UserEntityAccess  WHERE UserId = '<UserId>' AND EntityDefinitionId LIKE '<DurableId >%'