Salesforce 中文筆記

要如何在 list view 選擇多筆 record 後一鍵刪除呢？ 這個功能在 Salesforce 目前沒有內建。 你可以選擇下列幾種方式 安裝 APP 用 flow 來做 用 apex class 來做 安裝 App 有一個由 Salesforce Labs 釋出的 app ，名字很直白就叫做 Mass Delete 官方說明文字 A set of custom list buttons that you can add to your standard list views or related lists. Users can select any number of records and delete all of them with a single click. 優點 快速簡單，即裝即用。 缺點 僅支援下列幾個現成的 standard object，如果需要用在 custom object，需要進行一點客製修改。 支援 object:  Product Solution Contact Contract Lead Opportunity Account Asset Campaign Case 使用在 custom object 的修改教學參考： https://blog.cloudanalogy.com/salesforce-lightning-how-to-mass-delete-records-from-list-view/ 概念上來說就只要 clone 它的 Visualforce Page 然後改第一行的 controller 即可。 用 Flow 來做 教學影片： https://youtu.be/3cdj8QCtYvI 用 Apex Class 來做 https://muskanagarwal1499.blogspot.com/2022/06/mass-delete-records-using-list-button.html

When we want to customize a FieldHistory object, such as the Opportunity Field History , we would write a small program to check the modification status of all fields when the Opprotunity record is updated. However, some fields are unnecessary, or even should not be checked. For example, some system fields like CreateDate and IsDeleted. In concept, if a field is not Updateable, there is no need to check it. So how do we confirm if a field is Updateable or not? Here is a ready-made method: (Using Opportunity as an example): Opportunity . sObjectType . getDescribe (). fields . getMap (). get ( fieldName ). getDescribe (). isUpdateable () The plain translation of the above line is roughly as follows: Retrieve the field map of the Opportunity object, and then extract the properties of the specified field from the field map. One of the properties that can be checked is isUpdateable. 

Matching Rules 和 Duplicate Rules 在 Salesforce 中都是用來處理重複資料的功能。 Matching Rules 是用來定義如何將新增的記錄與現有的記錄匹配。當系統發現與現有記錄重複時，會提示使用者並建議把新記錄與現有記錄合併。 Duplicate Rules 則是用來定義當建立新的記錄時，如果發現重複的記錄，該如何處理。可以設定警告使用者或是禁止創建重複記錄。 總的來說，Matching Rules 是幫助使用者將重複記錄合併，Duplicate Rules 是防止創建重複記錄。 (by ChatGPT)

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 勾勾...

 症狀描述 明明已經將button拉到page layout上了，也將Page Layout指派給正確的Profile了，但是user還是看不到New/Edit/Delete的button。 在Record Page看不到button，在List View的地方也找不到。 可能的原因 在Profile只給了Read的權限，沒開其它權限。 解法 到Profile設定的Standard Object Permissions/Custom Object Permissions，把Create/Edit/Delete的權限勾起來即可。          

  最近為了一項關於 Knowledge 的任務感到傷腦筋，是關於要一次更新數萬篇 article 的任務。 背景說明 Salesforce 裡面的 Knowledge ，是一個特別的模組。有著特別的功能……以及一些特別的限制。隨便講幾個出來，背後可能都藏了無數人踩過的坑。(詳細內容可見文末之參考資料) 光看他的 object API name，既不像一般 custom object 一樣有著「__c」的後綴，也不像 standard object 一樣的乾淨俐落毫無後綴。而是帶著一個「__kav」的後綴。光這一點就獨步於全 org 了。 而此次我要做的 patch 任務，如果以其它 object 的概念來說，就是一次 update 數萬筆 record 而已。不管是要用 data loader，或是用 workbench，甚或是寫一支 Apex Code 去跑個 update，都不是什麼困難的事。 但對於 Knowledge 來說，可說是無比的麻煩。 因為已經 publish 的 article 是不容編輯的。 When an article is published, the PublishStatus field on the KnowledgeArticleVersion object is changed from “Draft” to Online. If an attempt is made to update a published article via API, a message will be received indicating that only Draft articles can be updated. (  https://help.salesforce.com/s/articleView?id=000333316&type=1  ) 若以手動更新 article 的方式來說，就是要做這些步驟 Edit the article as a draft。先把已經 publish 的 article 弄成 draft 的狀態。 Update the fields。把你要更新的值填入 article 上的欄位並 save。 Publish the artilce。把你新編輯好的 article publ...

Salesforce觸發的流程執行順序 Validation rules Assignment rules Auto-response rules Workflow rules (with immediate actions) Escalation rules 模擬考題 利用 workflow 去 update field，如果違反了 validation rule，那這個 update 會成功嗎？ 如果會失敗，會在畫面上顯示 validation rule 的 error message 嗎？ 擬答 只有成功，沒有失敗。

比較表  考照模擬題目： Production 有些 custom object 包含了機密資訊。若需要一個沙箱可以 包含 data record 排除所有機密資訊 每週 refresh 那敢問貴 App Builder 該如何是好？ 擬答： 使用 Partial Copy Sandbox 以及 Sandbox Template。

 # Salesforce考照心得 在Salesforce這個平台打滾了四年有餘，我終於動身去拿了第一張證照了。 當然，就像機車駕照一樣。有駕照的人並不一定真的懂得如何騎車。 擁有Salesforce證照也無法證明自己真的具備相應的能力。 他唯一能夠證明的是，我有意願及資源去支付200美金來把這個證照掛在身上。 在網路上，Salesforce的正體中文相關討論是稀缺的。 可能一來是因為台灣採用Salesforce的公司並不是極多，二來是相關從業人士都極為忙碌。 至少我放眼所及、熟稔Salesforce的台灣人們，沒有一個不是事業蒸蒸日上、生活風風光光，各有各的精采人生。 誰有那種閒時間在那邊跟你討論證照要怎麼考XD 「這種簡單資訊不是自己查一查就知道了嗎，如果連這種基本能力都沒有，那也不要考什麼證照了，包袱收一收去鄉下種苦瓜好了。」 話當然不是這樣說的。 所以我希望留下一些簡單的心得與歷程記錄，盼使來人少走一點點冤枉路。 如果有訛誤或是過時的資訊，歡迎留言或Email給我，謝謝！ ## 準備考試所需時間 四年/兩天/一小時？ 要拿到這張Salesforce Administrator證照，到底需要多久呢？ 保守一點說，我花了四年把Salesforce這個系統裡裡外外摸了個半透，大部份的功能都真的親手實際操作過，才敢應試。 技術上來說，大概花個兩天刷個300題考古題，就足以應試了。 偏激一點來說，從走進考場起算，報到完坐下來把幾十道題目回答完後瀟灑起身離去，從頭到尾不到一小時就可以取得證照了哦。  ## 正規準備方式 其實只怕你不學，不怕沒工具沒材料讓你學。 考試要具備的知識，都清清楚楚地寫在這裡了： https://trailhead.salesforce.com/credentials/administrator 就紮紮實實地把Trailhead的badge蒐集起來吧。 與其只想著要拿到證照，不如真的把握機會把這些知識技能學起來吧。 ## 報名考試 Salesforce是跟KRYTERION Webassessor合作的，諸如報名、繳費、考試，都是在這個網站上進行。 https://www.webassessor.com/salesforce 所以第一步就是得註冊一個Webassessor的帳號。(這個帳號跟Salesforce的是獨立的) 註冊...

 所謂 亂掉 ，常見的情況有二 1. 字體編碼亂掉：原本的中文字日文字或是歐洲文字或是不知道哪裡的神奇編碼文字，通通都變成亂碼了。 2. 欄位版面錯亂：原本應該要在A欄位的資料莫名被掛到B欄位下了。

Trailhead教學-Bulk Apex  關於什麼是有效率的code，什麼是浪費資源的code。 其中解釋了： 在trigger中預設使用迴圈來處理bulk，而非逐筆record處理。 用inner query的技巧，直接獲得各account的related opportunity SELECT ... FROM ... WHERE ... IN ...(set)    例：[ SELECT Id , Name , CloseDate FROM Opportunity WHERE AccountId IN : Trigger . New ]。 也可以使用NOT IN，例： [ SELECT Id , Name FROM Account WHERE Id IN : Trigger . New AND Id NOT IN ( SELECT AccountId FROM Opportunity ) ] update/insert整個list，而不要逐筆record操作，以避免DML超過150的限制。