想要在 Salesforce Platform 上建立表單?您擁有多個選項,可跨越整個低程式碼到專業程式碼連續。代表低程式碼的是 Lightning 應用程式產生器中的「動態表單」和 Flow Builder 中的畫面流程。在連續的中間停留的功能是使用 LWC 擴充畫面流程,並使用 OmniStudio 建立面向客戶的表單。而代表 Pro-code 是 LWC 架構及其不斷成長的基本元件庫。

選項很好,但如何判斷哪一個 (或哪個組合) 是正確的選項?這就是此指南的開頭。

• **Takeaway #1:建立 Lightning 頁面的建立/編輯/檢視版面配置時,請使用「動態表單」。**您可能注意到此指南的比較表中缺少版面配置。繼續進行時,設定記錄詳細資料頁面的建議方法是使用 Lightning 應用程式產生器中的「動態表單」。請參閱「版面配置」一節,以取得為何我們預期不會進一步增強版面配置的詳細資訊。
• **Takeaway #2:如果您只需要為一個物件建立建立或編輯表單,請從 Lightning 頁面和「動態表單」開始。**這是在 Salesforce 平台上建立表單的最簡單方法。它也提供一些額外功能,例如控制欄位可視性的功能。如果您的需求較進階,請繼續閱讀。畫面流程、OmniStudio 或 Lightning Web 元件 (LWC) 可能更適合。
• **Takeaway #3:如果您要建立多頁表單或精靈,且沒有嚴格的 UX 或品牌需求,請從「畫面流程」開始。**畫面流程提供線性瀏覽架構,可協調多個表單。您可以使用 LWC 建構您自己的架構來在表單之間瀏覽,但我們建議讓「流程」為您執行繁重的工作,讓您可以專注於表單本身,而不必擔心表單狀態。
• **Takeaway #4:如果您需要 表單後面的其他邏輯或動作,請使用「畫面流程」、「OmniStudio」或 LWC。**這三種工具皆可讓您的解決方案執行建立或編輯單一記錄以外的工作。「更多」可能是更進階的邏輯,例如分支或迭代,或者可能是更多動作,例如與外部系統整合、傳送電子郵件或將通知推送至使用者的行動應用程式。
• **Takeaway #5:取得複雜的 UX 需求?需要動態處理可視性以外的項目?使用 LWC 或 Omniscript。**如果您的需求可以透過簡單主題與以欄為基礎的版面配置來達成,您可以直接在低程式碼產生器中建立表單。如需更精細地控制表單樣式,您需要 LWC 的最終彈性。如果您是 Industries 客戶,且需要像素完美的品牌標識或具有複雜階層資料,請使用 OmniStudio,這可讓您建立可處理複雜業務邏輯和資料轉換的消費者評分表單。
• **Takeaway #6:如果您需要測試自動化,請從 Lightning Web 元件開始。**您可以針對任何 LWC 撰寫單元測試,無論您計畫內嵌的位置為何。這可讓您建立更強大的測試策略,其中可能包含含有多筆記錄的大量測試和負數測試。請參閱 Salesforce Well-Architected - 測試策略,以取得建立測試的詳細資訊,協助您瞭解表單是否符合功能與非功能需求。

請記住,您的選擇不必是/或 - 您可以結合多個選項的功能。例如,如果您需要 Flow 的內建瀏覽系統以及 LWC 提供的完整樣式彈性,請同時使用。

下表概述使用 Salesforce 建立表單的可用工具,以及其必要技能和授權考量事項。稍後我們將深入瞭解每個工具支援的特定功能,以及如何在點擊型工具和程式碼型工具之間選擇 (以及何時結合這些工具):

下表包含在選擇產品時要考慮的決策點概觀,以及您應對每個決策點提出的問題。在本指南的其餘部分,我們將深入探討這些主題。

以下是我們在比較表格中使用的詞彙及其定義:

• **可用:**與基本考量事項一起運作。
• **非理想:**可以運作,但不是最佳工具。
• **藍圖:**預估在未來 12 個月 (2025 年 6 月) 內的支援。
• 未來:估計在未來 12 個月後的支援。
• **不可用:**未來 12 個月內沒有計畫支援此功能。

如同承諾,讓我們開始深入瞭解「動態表單」、「畫面流程」、「OmniStudio」、「含內嵌 LWC 的畫面流程」與 LWC 架構本身之間的各種比較點和功能差異。

如果您的表單針對單一 Salesforce 物件執行,我們比較的任何工具都會運作。使用跨物件或物件不符的形式,情況會變得更複雜。透過物件無效,我們指不會對應至任何 Salesforce 物件的輸入。或許您的表單代表您要傳送至外部服務的資料結構,例如 Stripe 或 DocuSign。或者,您在表單中使用數個輸入來計算值,然後將該值認可至資料庫。

• 表單會對哪些物件進行操作?
• 是否只是一個物件,還是有多個物件?
• 您是否使用特定的物件 (例如帳戶、連絡人、機會、商機和個案),或您的表單也需要與其他物件搭配使用?

針對跨物件和物件不相符的形式,Flow 和 OmniStudio 皆是固定的選項。流程畫面中提供的元件本質上為不明智,因此您可以在背景中選擇要如何處理該資料。例如,使用在單一表單中輸入的資料建立多個背景記錄,或使用資料執行其他動作,例如產生 Chatter 貼文、傳送 Slack 訊息、傳送電子郵件或連線至外部服務。

針對簡單的個案,使用現有的 LWC 元件 (例如 Lightning 可以是降低所需程式碼以提供強大的解決方案的一個簡單方法。不過,針對涉及多個物件的情境,流程可提供所有物件的全方位控制,並移除開發人員探索複雜關係和相依性的需求。

OmniStudio 會更進一步地處理事項,且完全為物件感知—它會將使用者看到的表單與基本資料模型分開。OmniStudio 會改為使用如「資料對應工具」和「整合程序」等工具來操作基礎 JSON,然後將其對應至 Salesforce 物件 (或外部資料)。「資料對應器」和「整合程序」是將您的 OmniStudio 表單與 Salesforce 內部和外部資料連線至 Salesforce 的兩個關鍵元件。使用拖放元素,您可以使用外部系統中的複雜階層資料,然後根據資料需要移至的位置,將資料轉換為符合您的需求。它們也允許您使用公式對陣列或資料清單執行數學和邏輯,如同 Apex。

OmniStudio 整合

如果您可以從單一畫面表單取得所有使用者輸入,請從「動態表單」開始。然而,雖然記錄頁面中的「動態表單」可以使用「路徑」功能,以寬鬆地代表您業務流程中的各個階段,但可能不適合您大多數的使用個案。

• 您是否需要單一畫面,或使用者需要在多個畫面之間瀏覽才能完成工作?
• 您是否要讓使用者看見視覺化說明其填寫表單流程的進度?
• 您的使用者是否需要以特定順序填寫每個畫面上的資訊,或者他們是否可以視需要在畫面之間來回移動?

如果您需要的功能比「動態表單」所提供的更多,則 Flow、OmniStudio 和 LWC 之間的選擇也會取決於其他幾個問題:

• 您的小組擁有哪些技能?針對更具管理力的組織,建議您從「流程」開始。如果您有 Industries 解決方案,且您的小組已熟悉 OmniStudio,且您的專案具有嚴格的 UX 需求,請從 OmniStudio 開始。
• 在表單底部顯示瀏覽列是否可以?如果畫面流程和 Omniscript 瀏覽體驗是不想要的 UX,請傾向 LWC。
• 表單後面必須發生什麼事?如果您需要管理員可設定的行為,請建立流程,或針對基本變更 (例如變更欄位標籤) 建立 Omniscript。否則,針對複雜的多物件關係,請建立 Omniscript 或 LWC。
• 如果您選擇 Flow 或 OmniStudio,您可能仍需要建立 LWC 以達成正確的 UX。如果您已經建立 LWC 來正確設定表單的樣式,請考慮是否過度將該元件內嵌在流程中。

另一方面,如果您的解決方案看起來像精靈,使用者可在多個畫面之間瀏覽,請考慮使用 Flow 或 OmniStudio。流程與 OmniStudio 隨附內建的瀏覽模型,因此您無須建立和維護串連的 LWC。瀏覽為線性,具有正向動作、反向動作,以及用來儲存表單的機制以供稍後使用。如果表單符合您的目的,您也可以使用非線性瀏覽來建立表單。如需使用畫面流程的最佳範例,請查看 Salesforce Lab 的「數位商店稽核」封裝。

OmniStudio 透過提供標準瀏覽中呈現表單中「步驟」的進度指標,提供重要的瀏覽優勢。此步驟檢視會自動顯示使用者在指定多步驟表單上的位置。不同於「流程」,其可讓使用者按一下表單的各個步驟,在畫面之間進行跳轉。

無論您是建立單螢幕或多螢幕表單,請確保表單已簡化,讓使用者能夠輕鬆瀏覽。

如果您將表單內嵌在標準 Lightning 記錄頁面中,我們比較的任何工具都會運作,但請注意「動態表單」目前僅適用於桌上型電腦。不過,如果您想要提供讓使用者從其他位置存取表單的體驗,您可能需要考慮其他選項。

• 使用者是否需要透過桌上型電腦、行動裝置或兩者存取表單?
• 使用者是否應能夠透過公用程式列從應用程式中的任何位置存取表單?
• 您是否要使用快速動作讓使用者填寫表單而不必離開目前所在的頁面?
• 您的表單是否必須在外部網站上可供使用?

由於它們需要記錄內容,因此只有 Lightning 記錄頁面支援「動態表單」。不過,Experience Cloud 頁面不支援「動態表單」。此限制已存在,因為 Experience Cloud 不使用「動態表單」相依的基礎架構 頁面。我們正在根據 Experience Cloud 中「動態表單」的要求來評估此項目。

您可以建立需要記錄內容的流程或全域運作的流程。因此,您可以在各種位置內嵌流程。針對記錄相關流程,這可能是 Lightning 記錄頁面、Experience Cloud 記錄頁面、物件特定動作或「動作與建議」部署。針對全域流程,這可能是公用程式列、其他 Lightning 或體驗產生器頁面、Snap 或外部應用程式。目前不支援將流程作為全域動作,但您可以將流程包含在 Aura 元件中作為因應措施。

OmniStudio 可讓您建立可編輯的 FlexCard 和 Omniscript,您幾乎可將其放置在您可以放置流程的任何位置。不過,雖然可編輯,但無法封裝。

LWC 支援高度的可重複使用性,因為您正在建立可透過 Salesforce、社群甚至在開放程式碼專案中的中繼資料與目標相關聯的元件。LWC 元件也可以透過 Lightning Out 內嵌在您自己的網站內。

在外部網站上 Lightning Out

Lightning Web 元件目前不支援作為快速動作 (物件特定或全域動作),但您可以將 LWC 封裝在 Aura 元件中作為因應措施 (就像您使用流程一樣)。LWC 元件也可以使用 Lightning 流程 元件啟動流程。

OmniStudio 優於透過 OmniOut 功能向外部網站公開內容。透過 OmniStudio 和 OmniOut,您可以將 OmniScript 表單和 FlexCard 元件編譯為標準元件,並在第三方網站或應用程式中將其在平台外執行。

目前 Mobile SDK 範本中未正式支援本指南涵蓋的任何格式技術。如果 Mobile SDK 對您的使用個案至關重要,您最好在行動應用程式中原生建立表單或建立 Visualforce 頁面,同時牢記 Salesforce 結構正確的 尺寸規格指引。

**路線圖備註:**Mobile SDK 小組正在主動支援 Visualforce 頁面中的 LWC。

如果您需要使用表單中的值來建立或更新記錄,則「動態表單」十分適用。針對任何超出這些功能,您需要利用 Flow、OmniStudio 或 LWC。這些功能可能包含決策或迭代的層級,或使用表單中的輸入產生 Slack 貼文或電子郵件。

• 您希望在背景執行的動作或邏輯為何?
• 您的資料模型是否包含階層資料?
• 您的表單是否需要在單一交易內或跨多個交易完成其作業?
• 您是否需要與外部系統整合?
• 您對可重複使用性和模組性有何需求?

流程提供標準動作以張貼至 Slack、傳送電子郵件和與 Quip 文件互動,因此您不需要撰寫程式碼來進行這些作業。LWC 透過使用與 使用者介面 API 互動的電線轉接器,提供與單一記錄和相關物件的豐富互動。當使用 getListInfoByName 的電線時,LWC 也可以與多個記錄互動。

Lightning Web 元件透過電線轉接器進行互動

如上所述,OmniStudio 使用整合程序和資料對應器,輕鬆地將外部和內部的資料提取並轉換至 Salesforce。由於您可以使用許多免程式碼函數,因此可使資料集以各種層級的關係壓平並展開。

**路線圖備註:**流程即將支援更新插入記錄集合的功能,以及管理階層資料。

流程、OmniStudio 和 LWC 皆與 Apex 整合,因此您可以輕鬆地填補選擇的任何解決方案中的任何間隙。例如,如果您需要從 LWC 篩選記錄,您可以一律使用 Apex 的電線轉接器來建立複雜的 SOQL 查詢。如果您因按一下情節而感到困惑,請將 Flow 或 OmniStudio 視為適用於伺服器端需求的 Apex 控制項可行替代方案。

此處的次要問題是您要立即認可動作,還是將動作延後至表單的特定部分。如果您使用多頁表單,這特別有用。流程可讓您輕鬆地從多個表單 (流程畫面) 結合輸入,並在精靈 (流程) 中稍後使用這些輸入來執行一些作業。事實上,我們建議以這種方式設計流程—在結尾執行動作—以防使用者在畫面之間反向跳轉,變更其回答。

交易和 管理員限制是 Salesforce Platform 的一種生活方式。如果您的使用個案相當簡單,則控制特定作業發生的交易並不重要。不過,有一些使用個案會讓您想要將多個作業合併到單一 交易中,而非在多個交易之間執行。一些範例:

• 回復或不回復:這就是問題。假設您的表單在背景建立多個記錄。如果第三個記錄無法建立,是否應回復前兩個記錄?如果您的每個動作彼此獨立,請隨時在個別的交易中執行這些動作。不過,如果這些項目相依,且您希望其中一個失敗也回復其他項目,請在單一交易中實作。如果您的表單在「流程」中,您可以使用「錯誤」路徑中的「回復」元素來回復交易並確保資料完整性。
• 對管理員限制的下游影響:尤其是當您的表單建立或更新記錄時,請考量該作業的下游影響為何。根據此記錄變更,會觸發哪些程序、工作流程規則、流程觸發、Apex 觸發或儲存順序中的其他項目?這些集合變更會如何影響在該交易中耗用的管理員限制?如果特定記錄變更會造成許多影響您限制的下游變更,請考慮將該記錄變更隔離至其自己的交易。
• 批次處理:即使是在 UI 內容中,您也可能需要同時批次多個更新。假設您的多畫面表單重複處理大量記錄。請等到您收集所有記錄的更新,然後提交一個要求來更新所有記錄,而不是在每個畫面之後認可記錄更新。

當您使用「動態表單」建立或編輯記錄時,您只會執行一個作業,且該作業一律是淨新交易的開始。

建立畫面流程時,您可以大幅控制在指定交易中發生的狀況。畫面與本機動作會作為交易之間的邊界。以下是在畫面流程結構中如何管理交易的概況摘要。

1. 一般使用者與畫面互動,然後按一下「下一步」。
2. 用戶端會使用輸入將要求張貼至 API。
3. API 接收要求,且會開啟交易與資料庫連線。API 接著呼叫流程引擎來叫用要求。
4. 「流程」引擎會在流程定義中接管並遵循適當的路徑,直到它達到「畫面」或「本機動作」節點為止。接著引擎會將該節點的相關資訊傳回給 API。
5. API 會建立一個回應物件,其中包含要呈現的下個畫面的詳細資料,並將該物件傳回給用戶端。此時系統會認可資料庫變更 (追蹤 儲存訂單執行),並關閉資料庫連線和交易。
6. 用戶端使用 API 回應來呈現下一個畫面讓使用者互動。
7. 從步驟 1 重複此步驟。

換句話說,畫面會「中斷」交易。發生此情況時,系統會認可任何待處理動作或 DML、結束先前的交易,並開始新的交易。

正確的設計是您在指定交易中分組的作業。讓我們逐步解說一些範例。

在左側,您可以看見在多個畫面收集輸入的流程,然後在一個交易中執行數個動作。

右側的流程會在個別的交易中執行每個作業。

假設您的流程會建立記錄、更新記錄,然後建立更多記錄,如右側的下一個流程所示。

在此情節下,如果前兩個元素成功,而最後一個元素失敗,則前兩個 DML 作業仍會建立並更新這些記錄,而第三個 DML 作業則不會。

透過使用「回復記錄」元素,如果所有三個作業都必須同時進行,您可以確保整個交易都會回復,如左側的最終流程所示。

如需詳細資料,請查看「交易中的流程」和「交易中的流程大量處理」。Salesforce Well-Architected 的「自動化」區段也會深入瞭解此 資料處理。

您從 LWC 控制交易的能力取決於 LWC 用來執行其作業的基本服務。如果您使用 Lightning 記錄格式基本元件,則在提交表單後,基本作業 (建立或更新記錄) 會在獨立交易中發生。

一般而言,這些規則適用於:

• 每個 UI API 呼叫都會隔離為其自己的交易。
• 如果您需要在單一交易中執行多個作業,請將輸入傳送至伺服器端技術,例如 Apex 控制項或流程。該技術適用的一般交易規則。

Flow、OmniStudio 和 LWC 都支援平台事件 (適用於以 事件為導向的結構) 和 API 整合。除了自訂 Apex 程式碼外,Flow 與 OmniStudio 都支援整合 API 的陳述性機制。

如果您需要連線至 Mulesoft API 或 RPA 機器人,請使用 Mulesoft Services。這會產生「外部服務」。

External 整合 (透過 Mulesoft API 和 RPA 機器人) 的外部整合

如果 API 有 OpenAPI 結構描述,請建立「外部服務」。

透過 OpenAPI 結構描述對 API 的外部整合

否則,請使用「流程」中的「HTTP 呼叫」功能,或使用 OmniStudio 中的「HTTP 動作」。流程的 HTTP 呼叫由「外部服務」提供技術支援。

透過 HTTP 的外部整合

OmniStudio 提供一組豐富的整合功能,可透過「整合程序」呼叫外部系統,並使用「資料對應器」轉換資料。(如需詳細資訊,請參閱 物件影響)

無論您是使用自訂 Apex 還是外部服務來實作,呼叫都是呼叫。以下是您需要瞭解的事項。

1. 呼叫可能需要很長的時間。
2. 當同步執行呼叫時,呼叫會在資料庫交易開啟時執行。
3. 如果您有待處理的資料庫作業,Salesforce 不會讓您保持資料庫交易開啟狀態。

要記住的主要限制是所謂的「**髒交易」**的危險,其中您執行建立、更新或刪除作業,然後在相同的交易中執行呼叫。由於上述考量事項 #3 不允許使用此模式,這當然存在於考量事項 #1 與 #2 之故。

在「流程」中,您可以透過中斷交易來解決此限制。請記住,畫面與本機動作都會重新導入瀏覽器內容,這會中斷交易。雖然您在使用外部呼叫時可以使用畫面和本機動作,但我們建議在可叫用進階設定中啟用「交易控制」。「交易控制」是可叫用動作的功能,可讓您在進行呼叫之前自動結束交易。您可以透過在叫用動作的「進階」區段中選取「一律開始新的交易」來啟用「交易控制」。

如需有關 Apex 呼叫、外部服務和一般資料整合功能的深入指引,請參閱《與 Salesforce 整合資料的結構設計師指南》。

「動態表單」不支援重複使用。每個「動態表單」都會繫結至特定物件的特定 Lightning 記錄頁面 (雖然您可以將該 Lightning 記錄頁面指派給多個應用程式、設定檔等)。

就像您可以撰寫要在多個其他元件之間使用的文件庫、公用程式和元件一樣,您可以在使用 **子流程**的功能建立流程時套用類似的設計模式。將您的流程儲存在較小的模組化分類中,然後使用「子流程」元素從其他流程呼叫流程。如果您的設計需要此流程,您可以建立一個流程,此流程可獨立且作為另一個流程的子流程有用。

OmniStudio 本身為模組化而建立。「資料對應器」、「Omniscript」、「FlexCard」和「整合程序」皆獨立建立,且可以互換運作。此外,FlexCard 可以建立為 LWC 元件,這些元件可內嵌在其他 LWC、Omniscript、記錄頁面和 Experience Cloud 網站中。

畫面流程、Omniscript 和 LWC 皆可建立以重複使用,並內嵌在各種位置,包括外部網站和 Lightning Out 應用程式。當您將解決方案設計為可編譯時,您會得到其他優點,例如適應性和穩定性。

用於建立或更新記錄的所有技術皆遵循系統層級驗證,無論是傳統驗證規則還是內建於 Apex 觸發中的自訂驗證。無論您使用哪種技術來執行記錄變更,每個變更都會通過儲存順序。這表示除了驗證規則之外,記錄變更也會由任何數量的儲存前或儲存後流程、觸發、升級規則、指派規則等處理。如果您尚未準備好,請務必將 Apex 加入書籤並熟悉 Apex 執行順序。

• 您的表單是否有系統層級驗證以外的其他需求?
• 您是否需要在表單中動態將欄位設定為必要或唯讀?

流程畫面或 Omniscript 步驟上的輸入本質上為未繫結,因此表單本身不會原生遵循與特定物件相關聯的系統級驗證。然而,您用來建立或更新記錄的任何值都會由儲存順序處理,這表示這些值會通過物件的系統級驗證。不過,請注意,並非所有畫面流程元件都支援輸入驗證。自 Summer '24 起,不支援輸入驗證的剩餘畫面元件為選項按鈕、選項清單、多重選擇選項清單、核取方塊群組和選項對應。

如同版面配置,「動態表單」可讓您在頁面層級設定必要性與唯讀狀態。不過,您無法覆寫系統層級設定。

流程提供自訂表單輸入驗證的彈性。雖然某些檢查是在用戶端執行 (例如標記遺失的必要欄位或不相容的值),但用戶端驗證不會阻止使用者嘗試瀏覽。實際驗證會在伺服器上進行。當使用者按一下「下一步」 時,流程會將輸入傳送至伺服器進行驗證。如果任何輸入傳回為無效,則會封鎖瀏覽,並顯示適當的錯誤。伺服器會透過檢查:

1. 輸入的必要性設定,或輸入的值是否與基本資料類型相容。
2. 該輸入的自訂驗證:多個標準元件 (「核取方塊」、「貨幣」、「日期」、「日期/時間」、「長文字區域」、「數字」、「密碼」和「文字」) 支援每個畫面的自訂驗證。提供布林值公式運算式和錯誤訊息,以在未符合公式運算式時顯示。
3. 基本元件的自訂驗證:如果您要為流程建立自訂 LWC,請將您自己的驗證程式碼新增至 validate() 方法。

OmniStudio 透過「設定錯誤」 動作,搭配「條件檢視」 和「傳訊」 元件,提供豐富的錯誤和驗證處理功能。

在 LWC 端,大多數基本元件都會執行自己的用戶端驗證。例如,Lightning 記錄格式遵循系統層級需求,但不遵循頁面層級需求。針對您的自訂元件,您可以 Build Your Own 驗證機制。

需要使用者輸入資料的欄位應在表單中提前顯示。在提交表單前,請盡可能在用戶端驗證使用者輸入。如需簡化表單的更多最佳作法,請參閱 Salesforce Well-Architected - 參與中的表單指引。

一般而言,安全性是一個複雜的主題,當涉及建立表單時,您可能甚至不會考慮到許多考量事項。在基礎層級,您會想要確保表單在正確的內容中執行,且使用者擁有使用其基本資料所需的權限。但除此之外,您也可能想要採取額外的措施來清除 Rich Text 欄位中潛在的惡意程式碼或 URL、防止特定使用者完全無法存取表單,或限制管理員未來可能內嵌表單的位置類型。選擇工具之前,請務必徹底記錄您的安全性需求。Salesforce 結構正確的 安全性原則範本包含此類型文件的原則。

• 表單是否應在執行某些作業前檢查使用者的存取權?
• 您應該消毒使用者輸入嗎?
• 您想要控制可以存取表單的人員嗎?
• 您想要控制表單的內嵌位置嗎?

當在 **使用者環境中**執行某些作業時,Salesforce 會強制執行一系列的存取檢查,包括根據您組織的共用規則驗證欄位級安全性、CRUD 權限和記錄存取權。例如,只有在使用者能夠更新個案、適當的欄位級安全性,以及對問題記錄的存取權時,才能執行個案更新表單。但如果您希望使用者能夠在使用您的表單時執行特定作業,而不是透過任何其他表單或互動,該怎麼辦?這就是 **系統內容**的開頭。

系統內容是提升執行中使用者在工作階段期間權限的方式,因此使用者不需要 (例如,更新「個案」物件的存取權) 才能成功完成個案更新表單。這對於未經驗證的社群特別有用。您可以將表單設定為在系統環境中執行,而不是授與來賓使用者潛在危險的技能。

當然,系統內容是雙邊形的劍,您只能在需要時使用。當表單在系統環境中執行時,每個單一 CRUD 作業都會略過物件和欄位級安全性和共用,而不只是您關注的特定作業。另請注意,系統內容並不影響 Salesforce 將執行動作使用者視為何,也就是您在「上次修改者」欄位中看到的名稱。針對您的表單執行的每個作業 (例如個案更新),執行動作使用者是執行使用者,即使表單在不同內容中執行也是如此。

「動態表單」、「Omniscript」與 LWC」一律在使用者環境中執行,無法覆寫此行為。

畫面流程依預設會在使用者環境中執行,但您可以將其設定為在系統環境中執行。您可以選擇流程應授與所有資料的存取權,還是仍應強制執行如共用的記錄級存取權。

• 如果您將 Lightning 元件內嵌在在系統環境中執行的流程中,則流程不會覆寫元件的內容。如果您需要略過使用者存取檢查,我們建議您使用流程來執行這些作業,並將適當的資料傳送至 Lightning 元件或傳送出來。某些立即可用的元件 (例如「對應」) 無法在系統環境中作業。
• 如果您的流程呼叫 Apex 動作,則需要瞭解一些細微差別。如果 Apex 類別設定為繼承共用,則無論流程設定為何,它都會在共用的系統環境中執行。如果類別沒有明確的共用宣告,則無論流程設定為何,類別都會在系統環境中執行,而不會共用。如果類別設定為共用或不共用,則它會這麼做,並覆寫流程的內容。

使用 Experience Cloud 網站在系統環境中查詢記錄:

如果您在 Experience Cloud 網站 (特別是未經驗證) 上的系統環境中執行流程,建議您僅將特定欄位儲存在「取得記錄」元素中。當您使用「流程」並將「取得記錄」元素的結果傳遞至子流程、可叫用動作或 Lightning 元件時,可透過瀏覽器的開發人員工具檢查該物件中的所有欄位。這可能會讓您可能不想要的 Experience Cloud 網站使用者可以使用欄位。透過在「取得記錄」元素中指定特定欄位,您可以確保僅顯示正確的欄位,即使系統內容已啟用也是如此。

請注意,Omniscript 邏輯是在用戶端執行,這可讓攻擊者使用瀏覽器的開發人員工具修改 Omniscript 的預期執行*,並*檢視整合程序、資料對應器和 Apex 方法呼叫的回應。當您使用 Omniscript 時,建議盡可能在伺服器端執行業務邏輯,並在透過 @InvocableMethod 註釋公開的任何 Apex 方法上實作輸入驗證規則。

消毒輸入:

若要保護您的組織免受惡意執行動作的影響,也請考慮輸入消毒。假設您在可公開存取的表單上有輸入,可對應至您組織中的 Rich Text 欄位。您可能會想考慮使用自動化方式去除任何可能隱藏惡意 URL 的 HTML。一般而言,在表單層級實作此消毒並不理想,因為您可以讓任意數量的來源寫入這些欄位。我們建議建立「快速欄位更新流程」(儲存前) 或在物件上使用現有的 Apex 觸發來刪除或修改任何可能輸入在表單中的潛在 HTML。

最佳作法:

• 除非您需要針對特定作業提升執行中使用者的存取權,否則請讓流程在其預設內容中執行。
• 基於安全考量,請避免在系統環境中為來賓使用者執行流程。建立具有有限欄位存取權的權限集,以改為指派給 Experience Cloud 網站的來賓使用者設定檔。
• 在 Experience Cloud 網站上查詢系統內容執行流程中的記錄時,請僅將您需要的欄位儲存在「取得記錄」元素或「可叫用動作」中。
• 如果流程執行各種作業,且並非所有作業都需要增強的存取權,請使用子流程來區隔應在系統環境中執行的作業。
• 如果您計畫將表單內嵌在外部網頁中,請考慮使用快速欄位更新流程或 Apex 觸發來清理使用者輸入,以移除 HTML,以避免惡意執行動作的任何潛在網路釣魚攻擊。

• 依預設,Omniscript、FlexCard 和 LWC 會在使用者環境中執行。
• LWC 預設會在使用者環境中執行,流程則會在使用者環境中執行,但您可以在 Apex 控制器中覆寫流程。
• 透過 UI API 執行的作業會在使用者環境中執行。
• 透過 Apex 控制項執行的作業取決於該類別。若要在系統模式中執行這些作業,請設定共用或不共用的 Apex 類別。

如果您需要控制可以存取表單的人員,您可以經常查看內嵌表單的容器。例如,您可以將 Lightning 頁面指派給特定應用程式、記錄類型或設定檔。如果表單中的某些輸入是敏感的,請使用可視性規則來進一步控制向人員顯示的內容;此功能適用於「動態表單」與畫面流程。

您可以將流程限制為特定設定檔或權限集,就像您可以 Apex 類別或 Visualforce 頁面一樣。依預設,流程不受限制,這表示任何具有「執行流程」使用者權限的使用者都可以執行流程。

如果您使用 OmniStudio,您可以設定 Apex 類別權限檢查器,以確保使用者需要對管理從 Omniscript、FlexCard、Classic 卡片或 REST API 呼叫之遠端動作的 Apex 類別明確存取權。

• 備註 Apex 類別權限檢查預設為針對新建立的指令檔啟用。不過,必須為任何現有指令檔手動啟用。
• 另請注意,Apex 類別權限檢查僅適用於 Apex 類別。我們也建議設定 整合程序和資料對應器的設定檔層級權限。

如需來賓使用者權限的詳細資料與最佳作法,請參閱:

• 來賓使用者記錄存取最佳作法
• 開發安全網站:已驗證與來賓使用者

最佳作法:

• 如果您要向來賓使用者公開流程,請僅授與來賓使用者設定檔其所需流程的存取權。雖然可以將「執行流程」新增至來賓使用者設定檔,但我們認為這是一種有風險的作法。
• 在系統環境中作業的流程需要特別小心*。強烈建議您將這些流程限制為特定使用者集,因為這些流程擁有較少的檢查和平衡功能來保護您的資料。*
• 確保在來賓使用者社群中執行 Apex 的任何 Omniscript 在 Apex 類別定義中具有共用權限。
• 在您的「來賓使用者」設定檔上,僅指派您要讓來賓使用者能夠呼叫的 Apex 類別,否則您無意中可能會向來賓使用者公開其他業務邏輯。

針對 LWC,您可以檢查執行使用者的權限指派,確認其是否具有特定標準或自訂權限。您可以直接從 JavaScript 匯入來自 @salesforce/userPermission 和 @salesforce/customPermission 範圍模組的 Salesforce 權限。或者您可以使用 Apex 來檢查相同項目。

只有在 Lightning Web 元件已新增為有效的 目標時,才能在指定的位置使用。例如,您可以讓元件在記錄頁面上可用,而無法作為公用程式列項目使用。

啟用畫面流程後,無論您是否打算隨處可用,畫面流程支援的所有位置皆可使用該流程。不過,Flow Builder 支援具有畫面的多種類型的流程。結點類型為「畫面流程」,但有一些其他專用類型僅限於特定位置。例如,Field Service 行動應用程式僅支援您猜到的 Field Service 行動流程。同樣的情況也適用於僅 Experience Cloud 支援的「連絡要求流程」。

無論流程類型為何,進行流程的個人都無法控制流程的內嵌位置。流程會在該流程類型支援的每個位置中提供使用。

如果您使用的是 Salesforce Industries,則在 Omniscript 方面會有輕微的警告:雖然您無法為 Omniscript 本身指定目標,但您可以為您可能要內嵌的 FlexCard 指定目標。

靜態形式屬於過去。今天,您需要為此使用者 (這次是此地) 以正確的內容與值來動態更新表單。讓我們討論一下 Salesforce 表單建立工具在此情況下可能發生的功能。

• 哪些類型的互動或條件應在您的表單中觸發動態回應?
• 當表單正在填寫時,您是否需要在背景中執行螢幕外作業?
• 您是否需要將欄位設定為可見、必要、唯讀或已停用,或根據表單輸入變更格式?

透過反應性畫面,畫面流程的互動性現已實現。反應性可讓流程畫面上的個別元件彼此通訊,讓畫面流程變得無限強大。

執行螢幕外資料作業:「畫面流程」提供透過「畫面動作」在相同畫面上提取資料的陳述性方法。畫面動作可讓您在畫面中的任何變更或使用者按一下「動作按鈕」元件時觸發自動啟動流程。接著,您可以將這些自動啟動流程的結果對應至相同的畫面,以免使用者需要瀏覽至其他畫面。

LWC 提供完整的電線轉接器,可讓您存取 Salesforce 資料,以動態填入表單元件中的資料,並讓開發人員透過 Apex 控制項更新、刪除和建立記錄。

Lightning Web 元件螢幕外資料作業

**可視性:**可視性可在所有表單建立工具中動態控制。「動態表單」、「Flow Builder」和 OmniStudio 透過元件可視性功能來解決此問題。透過此功能,您可以根據表單上的其他值,或使用者是否在行動裝置上,以宣告的方式顯示或隱藏欄位。

• 透過「動態表單」,您可以根據記錄欄位值、透過對應欄位相關的記錄和尺寸規格來控制可視性。
• 透過「流程」,您可以讓可視性規則以畫面上的其他輸入為基礎,以及在流程前期填入的其他資源,例如其他記錄中的公式或值。
  • **以裝置為基礎的規則:**這一開始並不明顯,但您可以使用公式在使用者在行動裝置上時顯示或隱藏特定欄位。撰寫可檢查 $User.UIThemeDisplayed 全域變數值的流程公式。如果值為 Theme4t,則表示使用者在 Salesforce 行動應用程式上。
  • **評估其他資源:**手動變數和公式參照僅會在伺服器上評估。因此,資源在第一次呈現畫面時擁有的任何值,都是在您瀏覽至另一個畫面之前所擁有的值。在瀏覽時,流程執行階段會向流程引擎 (伺服器) 提交要求,並取得手動變數和公式的最新值。如果您預期您的可視性規則會在使用者通過單一畫面時更新 (例如,Onblur),請確保您僅參照畫面上其他元件的值。
• 透過 OmniStudio,您可以設定「條件式檢視內容」,條件式顯示或隱藏元件。不過,您無法為輸入新增多個條件式檢視內容。

**條件式輸入狀態:**如果您需要動態控制其他任何內容,例如欄位為必要、停用或唯讀,您有一些選項。LWC 如預期提供輸入狀態的完整反應性控制權。透過反應性「畫面流程」元件,您可以針對支援的標準元件動態控制元件屬性,例如「唯讀」、「已停用」和「必要」,而 OmniStudio 支援元件特定屬性的完整範圍。如果您的需求指出您需要「流程」,且元件不支援特定屬性狀態,您可以建立可內嵌 LWC 以達到動態輸入狀態。

如果您需要動態控制其他任何內容,例如欄位是必要或唯讀,短期內最佳的投注是 LWC,您可以完全控制該內容。如果您有針對如何處理開啟或點擊的自訂需求,則特別是如此。

畫面流程中的反應性 LWC:建立可在畫面流程上反應或變更其他元件的 LWC 時,請參閱此 LWC 畫面流程最佳作法指南,以確保您的元件在流程執行階段引擎中完整整合,並如未來所預期運作。

現在可用於自訂事件。如果您的部分輸入或整個表單需要與頁面中的其他項目通訊,則 LWC 是您唯一的選項。

• 若要在相同的 DOM 樹狀結構內通訊,請使用 CustomEvent 介面。
• 若要跨 DOM 通訊,請使用 Lightning 傳訊服務。
• 如果您的目標容器不支援 Lightning 傳訊服務,請使用 pub/sub 模組。

• 如需詳細資料,請參閱《Lightning Web 元件開發指南》中的 與事件通訊和跨 DOM 通訊。
• 針對 OmniStudio,請參閱 從 Lightning Web 元件與 Omniscript 通訊。

為了提供最佳的使用者體驗,您必須確保表單的樣式與其內嵌應用程式或網站的其他樣式一致。若要達成此目標,這意味著從利用 Salesforce 提供的標準範本到建立完全利用設計中每個像素的自訂 CSS,以提供更明確的外觀與操作。

• 您所需的樣式和 CSS 有多複雜?
• 您是否需要自訂、像素完美的樣式,或是您可以使用標準主題?

FlexCard 是本指南涵蓋的唯一產品,可讓您直接以宣告的方式控制在工具中建立之 UI 的樣式與版面配置,無論是邊緣和填補、列印圖、色彩等。

「動態表單」與「流程」皆遵循陳述性主題功能。如果您需要控制 Salesforce 主題、體驗產生器品牌集或 LWR Experience Cloud 網站支援的功能以外,請考慮使用程式設計解決方案。

針對喜歡使用 CSS 的小組,您有幾個選項:

• 流程與 LWC 會繼承 標準設計權杖。
• Omniscript 和 FlexCard 包含可自訂設計系統的支援:Newport。
• 透過 LWC,您可以撰寫您自己的元件,並完全控制其 HTML 和 CSS。

我們建議盡可能使用主題與設計系統,讓您的外觀與操作一致地套用至您的所有內容。

提醒:您可以在流程中內嵌 Lightning 元件。因此,如果您需要像素完美控制表單的外觀與操作,但想要使用流程的其他優點,例如瀏覽模型,您可以擁有這兩種世界的最佳功能。相同的原則也適用於 Omniscript 與 FlexCard。

選擇好的版面配置對於設計簡化表單而言至關重要,其可讓資料輸入快速且有效率,並提高資料完整性。如需此主題的詳細資訊,請參閱「Salesforce Well-Architected - 表單」。

• 如何利用表單版面配置最佳化使用者體驗?
• 如何向使用者呈現現有資料,讓使用者更容易在表單中輸入新資料?

「動態表單」支援兩欄版面配置,並可分成包含欄位的個別區段。這些區段可以放置在元件中,例如索引標籤和折疊式,以建立易於使用且有組織的版面配置。

流程可以選擇性地使用「區段」元件呈現。透過區段,您最多可在流程畫面上新增四個欄,以及任意數量的區段。元件也可回應螢幕寬度,因此可在較小的螢幕上運作。最後,其可讓您將條件化可視性套用至整個區段,以便對區段內的多個欄位大量套用可視性。「流程區段」也支援欄標題,並提供類似的折疊式體驗,使用者可按一下標籤來摺疊整個區段。

Omniscript 具備各種版面配置選項,用於顯示欄位與資料。您可以建立資料區段,其中包含最多 12 個資料欄,包括條件式摺疊式折疊式。

透過 LWC,您可以使用 Lightning] 格式和支援的 Lightning] 欄位來控制版面配置。唯一的版面配置限制是來自 HTML/CSS 的版面配置限制。Lightning 遵循相關聯版面配置中的區段組態;例如,如果區段在版面配置中為兩欄,則此元件中為兩欄。

如果不同區域的使用者或使用不同語言的使用者可以存取您的表單,您必須確保您要用來建立表單的工具符合您的本地化需求。如需其他指引和建議,請參閱「Salesforce Well-Architected - 本地化」。特別針對表單,本地化需求通常涉及將文字元素翻譯成其他語言。

• 您的表單是否要在一個以上的國家或地區使用?
• 表單中的文字是否需要本地化為其他語言?

如果您已本地化自訂欄位,則會在「動態表單」上遵循這些翻譯的標籤。「動態表單」也會遵循您在 Lightning 應用程式產生器中指派給元件標籤和屬性的自訂標籤。

透過翻譯工作台的功能,流程支援翻譯所有標準與自訂畫面元件的使用者面向標籤。您可以本地化下列畫面元件的標籤、說明文字和錯誤訊息:文字、長文字區域、數字、貨幣、核取方塊、選項按鈕、選項清單、多重選擇選項清單、核取方塊群組、密碼、日期和日期/時間。

無內建翻譯支援立即可用的動作,例如「傳送電子郵件」或「張貼至 Chatter」。不過,有因應措施!如果您使用 自訂標籤定義翻譯的標籤,則在 Flow Builder 中進行設定時,您可以在動作或元件中參照該自訂標籤。建立參照自訂標籤的流程公式,並在流程中的適當位置參照該公式。

Omniscript 使用自訂標籤進行翻譯。請參閱 此說明文件,準備好您的 Omniscript 多國語言。

現在為 LWC。某些基本元件會自動繼承相關聯物件欄位、說明文字和驗證訊息的翻譯 (若已在翻譯工作台中進行設定 (例如 Lightning。

如果您需要在程式碼中導入新的可翻譯標籤,則自訂標籤仍是未寫的 hero。宣告您需要的自訂標籤,然後從 @salesforce/label 範圍模組將其匯入至您的元件。

有數種端對端測試自動化工具可供使用 (例如 Selenium),可讓您模擬使用者如何與您的表單互動。您可以針對任何標準或自訂 UI 撰寫這些測試,包括 Lightning 頁面和畫面流程。不過,請務必注意,這些測試類型無法驗證每個執行中方法的輸出。考量您對 UI 測試自動化的需求時,請務必考量這一點。

• 您是否需要自動化表單測試?
• 您需要執行哪些類型的測試?
• 測試自動化需要的細微度層級為何?

請考量您對 UI 測試自動化的需求。

單元測試可啟用更精確的自動化和驗證,此驗證適用於產業標準 CI/CD 系統和工具,可測試元件業務邏輯、其 JavaScript 控制項和其輸出。僅使用低程式碼,您將無法自行撰寫測試,但 Salesforce 會嚴格測試我們的端對端供應項目。

如果元件的方法足夠複雜,讓您想要個別測試方法,請將方法放入專屬的 JavaScript 檔案中。如此一來,您便可以將其匯入至 LWC 和使用如 import { sort } from 'c/utils'; 的 Jest 測試。

如需在 Salesforce 上建立端對端自動化的各種選項比較,請參閱 Salesforce 上的 UI 測試自動化。包含何時使用 ISV 的無程式碼解決方案、Build Your Own 自訂測試自動化解決方案,或使用如 Selenium WebDriver 或 WebdriverIO 等開放程式碼測試架構的考量事項。這些解決方案適用於 Salesforce 中的任何 UI 互動,無論是 Lightning 頁面中的「動態表單」、公用程式列中的畫面流程,或是快速動作流程中的 LWC。

將表單部署至生產環境後,您會想要確保表單有效使用。視您的使用個案而定,這可能表示從追蹤填入次數到使用者在提交資訊前花費填入次數的時間。選擇工具前,請務必識別您要追蹤的 KPI。

• 您是否需要追蹤表單的使用狀況?
• KPI 會決定表單是否有效使用?

如果您需要追蹤表單的整體使用狀況和採用狀況,請從低程式碼工具開始。「動態表單」與「畫面流程」皆可使用立即可用的自訂報告類型進行追蹤,但您會從「畫面流程」追蹤報告中得到更多細微性。如果您需要追蹤 LWC 的使用狀況,立即可用的可用性取決於您使用該 LWC 的位置。如果它位於 Lightning 頁面上,則可用於追蹤 Lightning 頁面用量的任何項目都會套用至您的 LWC。同樣的情況也適用於內嵌在流程中的 LWC。

「動態表單」本身並非立即可追蹤,但您可以透過 Lightning 用量物件追蹤父系 Lightning 頁面的用量。若要追蹤標準 Lightning 頁面,請使用「依頁面度量別的 Lightning 使用者」 自訂報告類型。針對自訂 Lightning 頁面上的相同項目,請使用「具有 Lightning 使用情況的使用者 (根據 FlexiPage 度量)」自訂報告類型。

若要追蹤特定表單的採用狀況 (而不只是其所在的頁面),Flow 會為您提供協助。使用「範例流程報告:「畫面流程」可回答如下的問題:

• 此表單的完成率為何?是否正確採用?
• 使用者需要多久才能完成此表單?
• 使用者花費最多時間在哪個畫面上?
• 使用者向後瀏覽的頻率為何?
• 錯誤的發生頻率為何?

如果標準報告不符合您的需求,請複製報告以進行您自己的變更,或使用「*畫面流程」*報告類型從頭開始 Build Your Own。

如果您使用封裝型 Omniscript 執行階段,您可以利用 OmniStudio for Vlocity Tracking Service。此服務會追蹤任何類型的事件。例如,您可以追蹤在 Omniscript 中完成步驟所花費的時間,以識別流程改善方式。在標準 OmniStudio 中支援此服務是 OmniStudio 小組的藍圖。

若要針對未內嵌在畫面流程、Omniscript 或 Lightning 頁面中的 LWC 追蹤相同項目,則沒有立即可用的選項。您可以使用 Apex 建立自訂解決方案。

當您需要將解決方案部署至較高層級的環境以進行測試或部署至生產環境時,可能會使用變更集或 DevOps Center 來執行此操作。這些部署選項完全支援「動態表單」、「流程」與 LWC。OmniStudio 需要個別的工具:IDX 工作台。

• 您打算如何部署表單?
• 您的表單會散佈至多個 Salesforce 組織嗎?

如果您是 ISV 或計畫將解決方案封裝在 AppExchange 上散佈的合作夥伴,我們建議您先查看「動態表單」、「流程」和「LWC」。OmniStudio 不支援封裝。

本指南專注於協助您瞭解「動態表單」、畫面流程、OmniStudio 和 LWC 可使用的功能和自訂層級。在高層級:

• LWC 是建立表單的最可自訂且強大的選項,但具有最少的護欄。您可以透過確保安全性與可調整性的方式來建立元件。
• 「動態表單」最不彈性,但發生錯誤的機會較少。
• Flow 與 OmniStudio 位於其中一處—比「動態表單」更強大,但不完全符合 LWC 的層級。透過相同的權杖,它們的護欄比「動態表單」少,但比自訂程式碼更難破壞。

如果有多個工具符合該帳單,則決定要決定哪個工具適合您的小組。其他「結構設計師決策指南」會介紹在做出該決策時要考量的其他層面。

我們不會在此處深入說明每個層面的詳細資料,但我們會為此文件正在評估的特定工具解譯這些層面。

專業技能:您的小組在所比較工具方面的專業知識為何?有多少製造人員已熟悉 LWC 或 JavaScript?若建立者是 Flow Builder 專家或表示有興趣進入 Flow Builder,該如何?一般而言,「動態表單」和「流程」技能對於建立表單的人員族群較廣泛,較容易達成。「動態表單」是最具陳述性的表單建立工具,一律比「流程」更容易學習。不過,Flow 小組致力於盡可能降低該長條。在複雜性方面,OmniStudio 位於「流程」與 LWC 之間的某一處,提供重要的表單建立超級能力。

交付委派:因為您的某些需求需要 LWC,這不表示您的整個解決方案需要使用 LWC 建立。請思考如何模組化建立解決方案,讓需要 LWC 的組件編碼,以及未在低程式碼解決方案中內建的組件。這麼做可最大化多元小組的效率,並確保每個人都會為其專長解決適當的問題。

現在我們來談一下「流程」和「LWC」。透過反應性畫面元件,畫面流程元件現在可以在相同畫面上彼此交談,為結構設計師、管理員和開發人員解鎖全新的工具箱。開發人員現在可以建立有意義的模組化元件,這些元件可在整個組織中重複使用,進而提高小組中每個人的生產力。開發人員可以使用標準和自訂「流程」元件混合來專注於解決新挑戰,並節省時間,以實現表單動態。使用「流程」中的反應性元件時,建立表單時,將「流程」與 LWC 混合的時間從未更適合。

永續性與長期擁有權:如果您有多步驟表單,最好使用「流程」或混合「流程」和 LWC 來開始。如果您有低程式碼小組維護解決方案,請思考如何讓解決方案能盡可能為該受眾設定並延伸。無論您選擇的任何工具,請將您的解決方案組織為可組合單位,以改善可維護性和穩定性。

今後,設定記錄詳細資料頁面的建議方式為使用 Lightning 頁面的 Lightning 應用程式產生器中的動態表單。我們有增強型版面配置已經過一段時間,而且該趨勢將持續。以下是原因:

• 「動態表單」更有彈性,您可以將欄位和區段直接放置在 Lightning 應用程式產生器中,在其中您可以利用區段、索引標籤和折疊式。就像您在 Lightning 頁面上使用元件一樣,您可以控制欄位和區段的可視性,而無須定義多個版面配置或記錄類型。
• 透過「可折疊式」與「索引標籤」元件,您可以限制一開始顯示的欄位數量。猜這意味著什麼?更快的頁面載入時間。
• 使用 Lightning 頁面管理版面配置較為簡單,因為您可以從 Lightning 應用程式產生器管理您頁面的所有內容,無論是頁面的內容或哪些使用者可存取頁面。您不再需要在版面配置中進行更新,才能在 Lightning 頁面中進行變更。此外,可視性規則的強大功能讓您不再需要建立多個頁面 (或版面配置) 來控制誰會在何時看見哪些欄位。這也表示您只需要將 Lightning 頁面指派給使用者,而不需要同時指派 Lightning 頁面與版面配置。

建議盡可能使用「動態表單」,並僅在必要時返回版面配置。如往常般,我們歡迎在「計畫交換」中提供對您組織影響最大的改善意見。

與「動態表單」、「畫面流程」、「OmniStudio」和 LWC 相關的任何效能考量事項都著重於這些技術本身的架構。以 LWC 為基礎的項目 (當然是 LWC 之外) 將會高於以 Aura 為基礎的項目。LWC 架構提供更好的效能,因為核心功能是在 Web 引擎中原生實作,而非透過架構抽象在 JavaScript 中實作。如果您不熟悉,請先閱讀此部落格貼文。

回到 2019 年,我們進行了一個比較 Aura 中相同功能與 LWC 中效能的 個案研究。由於將 DreamHouse 從 Aura 轉換為 LWC,因此開發體驗與目前的 Web 前端開發標準和模式更加一致,而且效能提升顯著。實驗室測量顯示冷快取的收益範圍為 **2.4% 到 24.7%,**並在相同兩個頁面上顯示熱快取的收益範圍為 31.83% 到 63.32%。

現在,我們的表單技術會使用哪個架構?換句話說,哪些格式技術受益於此優良的效能?

• 「動態表單」整合在 Lightning 頁面中繼資料中,其建立在使用 LWC 堆疊的基礎上,這將讓我們實作一些長期要求的功能。「動態表單」使用漸進式呈現作為效能優點,進而改善具有大量欄位之頁面的頁面載入時間。
• 「畫面流程」以 LWC 為基礎,大多數個別立即可用的元件現在已轉換為 LWC,但兩個立即可用的元件除外:檔案上載和影像。雖然流程小組將流程執行階段用戶端轉換為 LWC 及其大多數元件,但客戶仍需要將其 Aura 畫面元件轉換為 LWC。不僅如此,Salesforce 僅支援畫面流程中新反應性元件架構中的 LWC 元件。有一個優秀的 Trailhead 模組說明如何執行 開發人員適用的 Lightning Web 元件。當然如此:如果您正在考慮為畫面流程或任何其他容器建立自訂元件,請一律執行 LWC。
• 有一些版本的 OmniStudio 可供使用。如果您是長期客戶,您可能正在使用 Angular。我們鼓勵所有新客戶開始使用 LWC 型 Omniscript 和 FlexCard,並鼓勵現有客戶從 Angular 移轉。
• LWC 建立於 ...LWC 當然。這是免費註冊。

身為結構設計師,務必深入瞭解所有可用的選項,以及如何在特定使用個案中套用這些選項。針對在 Salesforce 上建立表單,選項範圍從低程式碼 (在 Lightning 應用程式產生器中使用「動態表單」、「Flow Builder 中的畫面流程」和 OmniStudio 中的 Omniscript) 到使用 Pro-code (使用 LWC 架構),其中包含畫面流程或 Omniscript 和 LWC 的組合。請記住此指南,並在您計畫在 Salesforce 上建立或重新設計表單時將其作為參考。如果您想要瞭解如何設計簡化且實用的表單,請諮詢 Salesforce Well-Architected:參與中。

協助我們確保我們發佈與您最相關的內容:進行我們的調查以提供此內容的回饋意見,並告訴我們您接下來想要看到的內容。