[Salesforce Admin 2026] Phần 5: Automation - Kỷ Nguyên Tự Động Hóa Gọi Tên Flow Builder (15%)
Nếu Data Model là nền móng của Salesforce, Configuration & Setup là lớp bảo mật, còn Object Manager & App Builder là nơi chúng ta định hình dữ liệu và giao diện, thì Automation chính là thứ khiến cả hệ thống bắt đầu “tự vận hành”.
Và khi học Salesforce Admin trong năm 2026, có một điều bạn cần xác định ngay từ đầu:
Automation trong Salesforce hiện đại = Flow Builder.
Đây không còn là lúc chúng ta học Workflow Rules, Process Builder rồi mới học Flow như một công cụ “nâng cao”. Thời đại đó đã qua.
1. Workflow Rules & Process Builder: Đã đến lúc “chia tay”
Salesforce đã kết thúc hỗ trợ cho Workflow Rules và Process Builder từ ngày 31/12/2025. Các automation cũ vẫn có thể tiếp tục chạy, nhưng Salesforce không còn cung cấp hỗ trợ hoặc sửa bug cho chúng nữa.
Điều này dẫn đến một nguyên tắc rất quan trọng cho Admin 2026:
Đừng đầu tư thời gian học cách xây automation mới bằng Workflow Rules hoặc Process Builder. Hãy tập trung vào Flow Builder.
Nếu bạn đang maintain một Org cũ, bạn vẫn có thể gặp:
- Workflow Rules đang Active.
- Process Builder đang Active.
- Các automation legacy chạy song song với Flow.
- Logic cũ cần được migrate sang Flow.
Salesforce cũng cung cấp Migrate to Flow để hỗ trợ chuyển đổi Workflow Rules và Process Builder sang Flow Builder.
Nhưng hãy nhớ một điểm rất quan trọng:
Migrate không có nghĩa là “bấm một nút rồi xong”.
Sau khi migrate, Admin vẫn phải kiểm tra logic, test trong Sandbox, xử lý những phần migrate chưa hoàn chỉnh và cuối cùng mới activate Flow rồi deactivate automation cũ.
Đối với người học Salesforce Admin 2026, tư duy nên chuyển từ:
Workflow Rule
↓
Process Builder
↓
Flow
sang:
Business Requirement
↓
Choose the right Flow type
↓
Build
↓
Test
↓
Activate
2. Flow Builder: “Con dao đa năng” của Salesforce Automation
Điểm mạnh nhất của Flow Builder là nó không chỉ giải quyết một kiểu automation.
Trong bài thi Admin, hãy đặc biệt nắm chắc ba loại Flow sau.
2.1. Record-Triggered Flow — Dữ liệu thay đổi, Flow tự chạy
Đây là loại Flow cực kỳ quan trọng.
Flow được kích hoạt khi một record được:
- Tạo mới.
- Cập nhật.
- Hoặc trong một số trường hợp, bị xóa.
Ví dụ:
Khi một Opportunity chuyển sang Closed Won, Salesforce tự động cập nhật Account, tạo Task cho Account Executive và gửi thông báo cho bộ phận triển khai.
Người dùng không cần bấm nút.
Record thay đổi → Flow chạy.
Đây chính là loại Flow bạn nên nghĩ tới đầu tiên khi câu hỏi có dạng:
“When a record is created/updated…”
hoặc:
“Automatically perform an action when…”
2.2. Screen Flow — Khi người dùng cần tương tác
Screen Flow dành cho những tình huống cần giao diện để người dùng nhập dữ liệu hoặc thực hiện từng bước.
Ví dụ:
Một Sales Rep muốn tạo một yêu cầu đặc biệt. Thay vì đưa họ vào một Record Page với hàng chục field, chúng ta xây một Screen Flow:
Step 1
Chọn khách hàng
↓
Step 2
Nhập thông tin yêu cầu
↓
Step 3
Chọn sản phẩm
↓
Step 4
Xác nhận
↓
Step 5
Tạo Record + thông báo
Điểm mấu chốt:
Có giao diện + có user interaction → nghĩ ngay đến Screen Flow.
Screen Flow đặc biệt hữu ích khi business process có nhiều bước hoặc cần hướng dẫn người dùng nhập dữ liệu theo một trình tự cụ thể.
2.3. Autolaunched Flow — Chạy ngầm phía sau
Autolaunched Flow không có giao diện Screen và không cần người dùng tương tác trực tiếp.
Nó thường được gọi bởi:
- Flow khác.
- Apex.
- REST API.
- Custom Button/Link.
- Flow Orchestration.
- Một automation hoặc process khác.
Có thể hình dung:
User / System
↓
Trigger
↓
Autolaunched Flow
↓
Business Logic
↓
Update / Create / Call Action
Đây là loại Flow rất phù hợp để tách business logic thành những module có thể tái sử dụng.
Một bài toán kinh doanh đủ “đô” để cần Flow
Hãy tưởng tượng công ty bán thiết bị công nghiệp.
Khi Sales tạo Opportunity:
- Nếu giá trị Opportunity trên 500 triệu → cần kiểm tra đặc biệt.
- Nếu discount vượt 10% → yêu cầu Sales Manager phê duyệt.
- Nếu discount vượt 20% → tiếp tục yêu cầu Director phê duyệt.
- Khi được duyệt → tự động cập nhật trạng thái.
- Tạo Task cho bộ phận Pricing.
- Gửi thông báo cho Sales.
- Nếu bị từ chối → yêu cầu Sales điều chỉnh lại discount.
- Nếu Opportunity chuyển Closed Won → tự động tạo các công việc triển khai.
Đây không còn là một câu chuyện “Update một field”.
Đây là business process có điều kiện, nhiều bước, nhiều người tham gia và nhiều automation liên kết với nhau.
Đó chính là lúc sức mạnh của Flow Builder bắt đầu phát huy.
3. Approval Process — Khi Automation cần một con người nói “Yes”
Có một nhóm bài toán mà Flow thông thường chưa phải câu trả lời cuối cùng:
Business yêu cầu một người có quyền phải phê duyệt.
Ví dụ điển hình nhất là duyệt chiết khấu bán hàng.
Giả sử công ty quy định:
Discount ≤ 10%
→ Sales tự xử lý
10% < Discount ≤ 20%
→ Sales Manager duyệt
Discount > 20%
→ Sales Manager
↓
Sales Director
Đây chính là tư duy của một multi-step approval process.
Một approval process thường cần ba nhóm thành phần quan trọng.
Entry Criteria
Xác định:
Record nào phải đi vào quy trình phê duyệt?
Ví dụ:
Opportunity Discount > 10%
AND
Opportunity Stage = "Negotiation"
Không đạt điều kiện → không cần approval.
Approvers
Xác định:
Ai là người có quyền phê duyệt?
Có thể là:
- User cụ thể.
- Manager.
- Queue.
- Group.
- Hoặc logic xác định approver theo business requirement.
Với quy trình nhiều tầng, approval có thể được chia thành nhiều stage/step.
Ví dụ:
Stage 1
Sales Manager
↓
Approved
↓
Stage 2
Sales Director
↓
Approved
↓
Final Approval
Actions
Sau khi Approve hoặc Reject, hệ thống có thể thực hiện các hành động tiếp theo.
Ví dụ:
Approved:
- Cập nhật Approval Status = Approved.
- Gửi notification cho Sales.
- Tạo Task cho Pricing.
- Tiếp tục quy trình bán hàng.
Rejected:
- Cập nhật Approval Status = Rejected.
- Gửi thông báo cho Sales.
- Yêu cầu điều chỉnh discount.
Trong Salesforce hiện đại, Approval cũng ngày càng gắn chặt với hệ sinh thái Flow. Flow Approval Processes cho phép xây dựng các approval process có stages, steps và decisions, đồng thời kết hợp approval steps với Screen Flow và background steps với Autolaunched Flow.
Vì vậy, đừng nhìn Approval và Flow như hai thế giới hoàn toàn tách biệt.
Hãy nhìn chúng như những mảnh ghép của cùng một hệ thống automation.
4. Mẹo thi Salesforce Admin: Đọc requirement trước, chọn tool sau
Đây là phần có thể giúp bạn tiết kiệm rất nhiều thời gian trong phòng thi.
Đừng nhìn thấy chữ automation rồi chọn Flow một cách máy móc.
Hãy tìm từ khóa hành vi trong requirement.
| Requirement trong câu hỏi | Công cụ nên nghĩ tới |
|---|---|
| Người dùng cần nhập dữ liệu từng bước | Screen Flow |
| Record được tạo/cập nhật → tự động xử lý | Record-Triggered Flow |
| Logic chạy ngầm, không cần giao diện | Autolaunched Flow |
| Cần người có quyền phê duyệt | Approval Process / Flow Approval Process |
| Automation legacy cũ | Migrate to Flow |
| Automation mới trong Salesforce 2026 | Flow Builder |
Một số pattern cực kỳ đáng nhớ:
“User needs to enter information through multiple steps” → Screen Flow
“When an Opportunity is updated…” → Record-Triggered Flow
“Run automatically in the background…” → Autolaunched Flow
“Manager must approve…” → Approval Process
“Replace an existing Workflow Rule/Process Builder…” → Migrate to Flow
5. Kết luận: Admin 2026 phải nghĩ bằng Flow
Nếu trước đây Salesforce Admin có thể học automation theo kiểu:
Workflow → Process Builder → Flow
thì trong năm 2026, cách học hiệu quả hơn là:
Requirement → Automation Pattern → Flow
Điều quan trọng không phải là bạn thuộc lòng hàng chục loại Flow.
Điều quan trọng là khi đọc một requirement, bạn có thể lập tức nhận ra:
Ai kích hoạt? Khi nào chạy? Có cần người dùng tương tác không? Có cần người phê duyệt không? Logic chạy ở đâu?
Trả lời được những câu hỏi đó, bạn sẽ chọn đúng công cụ.
Và nếu có một câu duy nhất cần ghi nhớ sau bài này, hãy ghi nhớ:
Salesforce Automation trong kỷ nguyên mới không còn xoay quanh Workflow Rules hay Process Builder. Hãy học cách tư duy bằng Flow Builder.
All rights reserved