Workday HCM

2) Dành cho ai + Khi nào nên dùng

Nhân viên dùng Core HCM để xem/cập nhật hồ sơ và dữ liệu cá nhân (nếu tenant bật). Quản lý và HR dùng để thay đổi job/tổ chức và các sự kiện vòng đời nhân sự.

• Nhân viên: xem/cập nhật thông tin liên hệ và chi tiết cá nhân (tuỳ tenant).
• Quản lý: khởi tạo thay đổi cho team, xem dữ liệu tổ chức/nhóm.
• HR: xử lý giao dịch vòng đời nhân sự và quản trị dữ liệu.
• Dùng tab này trước khi thay đổi bất cứ thứ gì ảnh hưởng đến điều kiện hưởng quyền lợi, cơ cấu tổ chức, hoặc báo cáo.

3) Vị trí trên điều hướng + Tab liên quan

Các điểm vào phổ biến: Search → tác vụ worker; Home → worklet People/Team; Hồ sơ worker → Related Actions. Tab liên quan: Recruiting & Hiring Security Business Processes Reporting.

• Tìm tác vụ theo “ý định”: “Change”, “Request”, “View”.
• Mở worker record trước khi cần thao tác theo ngữ cảnh.
• Dùng Inbox cho các bước follow-up (tài liệu, phê duyệt, xác nhận).
• Kiểm tra màn hình process/status khi thấy bị chậm.

4) Mô hình tư duy / Luồng

Thay đổi trong Core HCM thường có effective-dated và được kiểm soát bởi business processes. Bạn gửi giao dịch, Workday route phê duyệt/tác vụ, rồi cập nhật hồ sơ worker/org.

1. Xác định đúng đối tượng (worker, org, position/job).
2. Chạy đúng tác vụ thay đổi và đặt effective date.
3. Điền reason codes/bình luận theo yêu cầu tenant.
4. Gửi → route phê duyệt/tác vụ → hoàn tất cập nhật record.

5) Đối tượng & Thuật ngữ

Core HCM dựa trên các “đối tượng” nhất quán xuất hiện ở khắp nơi.

• Worker: hồ sơ trung tâm của một người (nhân viên/nhân sự hợp đồng).
• Supervisory Organization: cấu trúc tổ chức theo tuyến quản lý (phổ biến trong Workday).
• Company / Cost Center: thành phần tổ chức tài chính/hành chính (do tenant định nghĩa).
• Job Profile: định nghĩa chuẩn hoá vai trò (kỹ năng/yêu cầu).
• Position: một “slot” trong tổ chức (position management) hoặc Job (job management).
• Effective Date: ngày thay đổi bắt đầu có hiệu lực.

6) Máy trạng thái / Vòng đời

Vòng đời worker khác nhau theo tenant nhưng thường có các sự kiện vòng đời với trạng thái do business processes quản lý.

• Pre-hire/Candidate → Hire → Active.
• Các sự kiện thay đổi (job/comp/org) → chờ phê duyệt → hoàn tất.
• Các trạng thái leave/absence có thể tương tác với trạng thái worker.
• Termination/retire → inactive; lịch sử vẫn được lưu.
• Lưu ý: Nhãn cụ thể phụ thuộc cấu hình.

7) Các việc cốt lõi cần làm

Đây là các việc “core” thực tế mà hầu hết tenant hỗ trợ.

• Xem hồ sơ worker và các phân bổ tổ chức quan trọng.
• Yêu cầu/cập nhật thông tin cá nhân (nếu bật cho nhân viên).
• Khởi tạo thay đổi job/tổ chức (quản lý/HR).
• Đính kèm tài liệu hỗ trợ cho một giao dịch.
• Theo dõi thay đổi đã gửi từ phê duyệt đến hoàn tất.

8) Luồng chuẩn #1: Cập nhật thông tin cá nhân/liên hệ (nhân viên)

Dùng khi bạn cần cập nhật thông tin của chính mình mà tenant cho phép tự phục vụ.

1. Tìm tác vụ liên quan (ví dụ: “Change Contact Information”).
2. Xác nhận bạn đang sửa hồ sơ của chính mình (không phải người khác).
3. Nhập các trường cập nhật; giữ định dạng nhất quán (điện thoại, địa chỉ).
4. Đính kèm giấy tờ nếu tenant yêu cầu (hiếm; tuỳ tenant).
5. Gửi và đọc thông báo xác nhận.
6. Kiểm tra Inbox để xem có tác vụ follow-up không.
7. Xác minh thông tin mới hiển thị trên hồ sơ của bạn.

9) Luồng chuẩn #2: Khởi tạo thay đổi cho team (quản lý)

Dùng khi bạn cần một thay đổi chuẩn (chuyển org, đổi job) với vai trò quản lý và được cấp quyền.

1. Mở worker record (thành viên trong team).
2. Dùng Related Actions → chọn tác vụ phù hợp kiểu “Change Job/Move Worker” (tên tuỳ tenant).
3. Đặt effective date và lý do.
4. Điền kỹ các trường org/position/job bắt buộc.
5. Xem lại các tác động (comp, location, costing) nếu hệ thống hiển thị.
6. Gửi và xác nhận route/luồng phê duyệt.
7. Theo dõi Inbox để xử lý các tác vụ follow-up bạn sở hữu.

10) Điểm quyết định

11) Lỗi thường gặp (và cách tránh)

• Lỗi: Bỏ qua effective date. Tránh: luôn xác nhận khi nào thay đổi có hiệu lực.
• Lỗi: Chọn sai org. Tránh: đối chiếu supervisory org và tuyến quản lý.
• Lỗi: Gửi thiếu lý do/bình luận. Tránh: dùng reason codes bắt buộc để phục vụ audit/báo cáo.
• Lỗi: Coi Workday như bảng tính. Tránh: dùng giao dịch + phê duyệt (BPF), không chỉnh tay.
• Lỗi: Chia sẻ rộng dữ liệu worker đã xuất. Tránh: theo nguyên tắc tối thiểu quyền và chính sách.

12) Quyền hạn & Vai trò

Các thao tác Core HCM được kiểm soát rất chặt theo vai trò; quản lý/HR có thể thấy các tác vụ khác nhau trên cùng một worker record.

13) Dữ liệu & Tích hợp

Dữ liệu worker/org nền tảng thường cấp cho báo cáo và tích hợp; nếu tenant có mở, hãy dùng API/dịch vụ chính thức.

14) Thế nào là “làm tốt”

• Thay đổi được gửi qua đúng tác vụ và được route đúng.
• Effective dates và lý do nhất quán, truy vết được.
• Record nhất quán giữa các module liên quan (absence, recruiting, analytics).
• Tôn trọng ranh giới security/quyền truy cập.

15) Checklist: Trước khi làm + Sau khi làm

16) Bài lab (5–15 phút)

Mục tiêu: nắm layout worker record và các hành động an toàn.

1. Mở worker record của bạn và tìm org/manager và thông tin liên hệ.
2. Dùng Related Actions và liệt kê hành động nào thấy/không thấy (được phép vs bị ẩn).
3. Tìm một report “View” cho org/team của bạn và thử áp bộ lọc.
4. Nếu được phép xuất (export), thực hành xử lý an toàn: lưu/xoá theo chính sách.

17) Link tài liệu chính thức

• Tổng quan Workday HCM (các khu vực cốt lõi trong HCM).
• Workday business process framework (cơ chế route giao dịch).

2) Dành cho ai + Khi nào nên dùng

Quản lý thường khởi tạo nhu cầu tuyển và phê duyệt; HR thường quản lý offer và các bước tuân thủ. Dùng tab này khi bạn cần chuyển ứng viên sang hire mà không làm vỡ phê duyệt hoặc chất lượng dữ liệu.

• Quản lý tuyển dụng: phê duyệt requisition, phản hồi phỏng vấn, phê duyệt cuối.
• Recruiter/HR: tạo offer, bàn giao onboarding, các bước tuân thủ.
• Người phê duyệt: lãnh đạo tổ chức, chủ ngân sách (tuỳ tenant).
• Dùng trước khi phê duyệt offer/hire để kiểm tra lương và ngày bắt đầu.

3) Vị trí trên điều hướng + Tab liên quan

Điểm vào thường gặp: worklet/app Recruiting/Hiring, Search các tác vụ “Hire”, phê duyệt trong Inbox. Tab liên quan: Core HCM Business Processes Security.

• Dùng pipeline tuyển dụng/danh sách ứng viên (nếu bật).
• Mở requisition/candidate record, sau đó dùng Related Actions.
• Dùng Inbox để phê duyệt offer/các bước hire.
• Kiểm tra process status/history nếu bị kẹt ở khâu bàn giao.

4) Mô hình tư duy / Luồng

Tuyển dụng thường bắt đầu bằng một yêu cầu và kết thúc ở worker record—được điều khiển bởi business processes. Ứng viên thường trở thành pre-hire (thường gặp) rồi được hire vào position/job với effective dates.

1. Tạo/phê duyệt requisition hoặc yêu cầu tuyển (tuỳ tenant).
2. Đẩy ứng viên qua các giai đoạn; ghi nhận feedback phỏng vấn.
3. Chuẩn bị offer → review → gửi ký điện tử/chấp nhận.
4. Hire nhân sự vào position/job; kích hoạt các tác vụ onboarding.

5) Đối tượng & Thuật ngữ

• Job Requisition: yêu cầu tuyển đã được phê duyệt.
• Candidate: hồ sơ ứng viên trong pipeline.
• Pre-hire: hồ sơ tiền nhân viên dùng trước khi hire (khái niệm phổ biến).
• Offer: lương và điều khoản cần review/phê duyệt.
• Hire: giao dịch tạo/kích hoạt một worker.
• Business Process: bộ máy điều phối phê duyệt/tác vụ.

6) Máy trạng thái / Vòng đời

Tuyển dụng dựa trên các giai đoạn. Giai đoạn cụ thể tuỳ tenant, nhưng ý tưởng nhất quán: ứng viên tiến dần tới chấp nhận, rồi hire hoàn tất.

• Các giai đoạn pipeline: applied → screening → interview → offer → accepted (nhãn có thể khác).
• Trạng thái offer: draft → review → sent → accepted/declined.
• Trạng thái hire: initiated → approvals → completed (worker active vào ngày bắt đầu).
• Nếu bị từ chối: ứng viên có thể quay lại giai đoạn trước hoặc đóng theo quy tắc process.

7) Các việc cốt lõi cần làm

• Khởi tạo yêu cầu tuyển/requisition (quản lý/HR tuỳ tenant).
• Đẩy giai đoạn ứng viên và ghi nhận feedback.
• Chuẩn bị và route offer để review và ký.
• Hire ứng viên vào vị trí/job đang mở.
• Xác nhận các tác vụ onboarding và đồng bộ ngày bắt đầu.

8) Luồng chuẩn #1: Offer → chấp nhận (quản lý + HR)

Luồng này phù hợp với thực hành phổ biến: HR chuẩn bị offer và quản lý review trước khi gửi.

1. HR chuẩn bị chi tiết offer (lương, ngày bắt đầu, địa điểm).
2. Quản lý review offer trong Workday và thêm bình luận nếu cần.
3. HR route offer cho các phê duyệt bắt buộc (ngân sách/lãnh đạo).
4. Thư mời được tạo và gửi ký điện tử (tuỳ tenant).
5. Ứng viên chấp nhận; trạng thái cập nhật trong Workday.
6. HR thông báo quản lý và chuyển sang bước hire.

9) Luồng chuẩn #2: Hire một nhân sự vào position/job

Tập trung vào “giao dịch hire” để worker record active với dữ liệu org và vai trò đúng.

1. Mở hồ sơ candidate/pre-hire đã được chấp nhận.
2. Bắt đầu tác vụ “Hire” (tên tác vụ tuỳ tenant).
3. Chọn position/job opening (hoặc job profile) và supervisory org.
4. Nhập start date/effective date và các thông tin chính (location, time type).
5. Review chi tiết compensation nếu có trong luồng.
6. Đính kèm tài liệu bắt buộc (nếu tenant yêu cầu).
7. Gửi và theo dõi phê duyệt qua Inbox/status.

10) Điểm quyết định

11) Lỗi thường gặp (và cách tránh)

• Lỗi: Gửi offer khi chưa xong phê duyệt. Tránh: xác nhận các bước phê duyệt đã hoàn tất trước khi gửi.
• Lỗi: Gán sai supervisory org/manager. Tránh: kiểm tra tuyến báo cáo trước khi hire hoàn tất.
• Lỗi: Ngày bắt đầu lệch giữa các bước. Tránh: dùng một start date “chuẩn” và tái sử dụng.
• Lỗi: Thiếu file đính kèm/tài liệu chính sách. Tránh: dùng checklist theo vai trò/quốc gia.
• Lỗi: Hire vào sai position/job profile. Tránh: đối chiếu mã requisition/position.

12) Quyền hạn & Vai trò

Các tác vụ và phê duyệt tuyển dụng phụ thuộc phân quyền (manager, recruiter, HR partner, leadership). Security của tenant quyết định ai được khởi tạo vs ai được phê duyệt.

13) Dữ liệu & Tích hợp

Tuyển dụng thường tích hợp với background check và công cụ ký điện tử (tuỳ tenant). Nếu tenant mở API, dịch vụ sẽ nằm trong các thư mục chính thức.

14) Thế nào là “làm tốt”

• Dữ liệu offer và hire khớp nhau (start date, location, comp).
• Phê duyệt đầy đủ và truy vết được.
• Chuyển đổi candidate → worker sạch, ít phải sửa lại.
• Bàn giao onboarding tự động bắt đầu (hoặc được kích hoạt rõ ràng).

15) Checklist: Trước khi làm + Sau khi làm

16) Bài lab (5–15 phút)

Mục tiêu: học luồng tuyển dụng mà không tạo thay đổi thật (dùng sandbox nếu có).

1. Xem một demo tuyển dụng chính thống/ngắn để nắm thuật ngữ.
2. Trong tenant (hoặc training tenant), tìm tác vụ “Hire” và mở để xem trường bắt buộc (không gửi).
3. Mở một hồ sơ candidate/pre-hire mẫu (nếu có dữ liệu training) và khám phá Related Actions.
4. Liệt kê những phê duyệt có khả năng xảy ra trong tổ chức của bạn.

17) Link tài liệu chính thức

• Khung “employee journey” của Workday HCM (plan to hire → retire).
• Các demo quy trình tuyển dụng (tổng quan giao dịch hire).
• Business process framework (bộ máy phê duyệt/luồng công việc).

2) Dành cho ai + Khi nào nên dùng

Quản lý và nhân viên dùng các tính năng nhân tài trong các chu kỳ mục tiêu và review. HR/People thiết lập chu kỳ và theo dõi tỷ lệ hoàn tất.

• Nhân viên: mục tiêu, tự đánh giá, kế hoạch phát triển (nếu bật).
• Quản lý: check-in, đánh giá, dữ liệu cho hiệu chỉnh (calibration) (nếu bật).
• HR: thiết lập chu kỳ, tiêu chí đủ điều kiện, nhắc hạn, báo cáo.
• Dùng tab này ở đầu chu kỳ và trước các deadline.

3) Vị trí trên điều hướng + Tab liên quan

Điểm vào thường gặp: worklet/app Talent/Performance, tác vụ trong Inbox, và trang worker/team. Liên quan: Core HCM Reporting & Analytics Business Processes.

• Tìm bằng Search các tác vụ “Goals”, “Performance Review”, “Feedback” (tên có thể khác).
• Dùng Inbox cho tác vụ review và phê duyệt.
• Dùng dashboard đội nhóm (nếu có) để theo dõi tiến độ.
• Dùng báo cáo để tìm các mục chưa nộp.

4) Mô hình tư duy / Luồng

Chu kỳ nhân tài là luồng công việc có khung thời gian: tác vụ được giao cho nhân viên/quản lý, được route phê duyệt khi cần, rồi đóng để phục vụ báo cáo.

1. Chu kỳ mở → tác vụ xuất hiện trong Inbox.
2. Nhân viên/quản lý hoàn thành biểu mẫu và thêm bình luận.
3. Các bước phê duyệt/calibration (tuỳ chọn) được route theo vai trò.
4. Chu kỳ đóng → bắt đầu báo cáo và lập kế hoạch chu kỳ tiếp theo.

5) Đối tượng & Thuật ngữ

• Mục tiêu (Goal): kết quả đo lường được; có thể roll-up lên mục tiêu đội (nếu bật).
• Đánh giá (Review): tài liệu/tác vụ đánh giá có điểm/bình luận (nếu bật).
• Phản hồi (Feedback): ghi chú trong suốt chu kỳ (nếu bật).
• Kế hoạch phát triển (Development Plan): kế hoạch học tập/phát triển (nếu bật).
• Business Process: bộ máy điều phối tác vụ/phê duyệt.

6) Máy trạng thái / Vòng đời

Các artefact của chu kỳ thường đi từ draft → submitted → completed, có thể có bước phê duyệt của quản lý hoặc calibration.

• Draft: đang làm dở.
• Submitted: chờ quản lý/bước tiếp theo.
• In progress: đang route qua các tác vụ phê duyệt/calibration.
• Completed: đã đóng và có thể báo cáo.
• Nếu tenant không bật: Không áp dụng cho tool/tab này

7) Các việc cốt lõi cần làm

• Tạo/cập nhật mục tiêu (nếu bật).
• Hoàn thành tự đánh giá (nếu bật) kèm bằng chứng và ví dụ.
• Hoàn thành đánh giá của quản lý và nộp đúng hạn.
• Chạy báo cáo hoàn tất và nhắc các mục còn thiếu.
• Ghi nhận quyết định và bước tiếp theo (kế hoạch phát triển).

8) Luồng chuẩn #1: Nhân viên hoàn thành tự đánh giá

Dùng khi chu kỳ mở và bạn nhận tác vụ tự đánh giá.

1. Mở Inbox và bắt đầu tác vụ self-review.
2. Xem lại mục tiêu/kỳ vọng vai trò (nếu hiển thị).
3. Viết 3–5 bullet bằng chứng (dự án, chỉ số, kết quả).
4. Nêu phần học được và điểm cần cải thiện kèm hành động.
5. Lưu nháp, đọc lại cho rõ ràng, rồi submit.
6. Xác nhận trạng thái đã nộp và người sở hữu bước tiếp theo.

9) Luồng chuẩn #2: Quản lý hoàn thành đánh giá + nộp

Dùng khi bạn nhận tác vụ đánh giá cho nhân sự báo cáo trực tiếp.

1. Mở Inbox và chọn review của một nhân sự.
2. Đọc self-review và ghi chú hỗ trợ.
3. Thêm rating/bình luận theo rubric của tổ chức (nếu bật).
4. Ghi nhận điểm mạnh bằng ví dụ cụ thể.
5. Ghi nhận điểm cần phát triển kèm kế hoạch cụ thể.
6. Submit và xác nhận bước tiếp theo (calibration/acknowledgement).

10) Điểm quyết định

11) Lỗi thường gặp (và cách tránh)

• Lỗi: Bình luận mơ hồ. Tránh: dùng bằng chứng + kết quả + hành động tiếp theo.
• Lỗi: Điểm không khớp với nội dung. Tránh: đối chiếu rubric và ví dụ.
• Lỗi: Dồn hết vào ngày deadline. Tránh: nháp sớm, rồi tinh chỉnh.
• Lỗi: “Bất ngờ” trong review. Tránh: ghi feedback xuyên suốt chu kỳ.
• Lỗi: Dùng Workday khi tính năng chưa bật. Tránh: xác nhận khả năng tenant trước.

12) Quyền hạn & Vai trò

Quyền truy cập phụ thuộc vai trò (nhân viên/quản lý/HR) và phạm vi tổ chức; tác vụ được route qua business processes.

13) Dữ liệu & Tích hợp

Không áp dụng cho tool/tab này (nguồn chính thức công khai trong lần chạy này không nêu chi tiết tích hợp Talent; phụ thuộc tenant).

14) Thế nào là “làm tốt”

• Bài nộp đầy đủ, dựa trên bằng chứng, nhất quán trong đội.
• Quản lý nộp đúng hạn; ít phải sửa sau calibration.
• Hành động phát triển rõ ràng và theo dõi được.

15) Checklist: Trước khi làm + Sau khi làm

16) Bài lab (5–15 phút)

Mục tiêu: luyện viết feedback dựa trên bằng chứng thật nhanh.

1. Nháp 3 mục tiêu đo lường được cho vai trò của bạn (kể cả viết offline).
2. Viết 1 đoạn self-review cho mỗi mục tiêu: kết quả + bằng chứng + bài học.
3. Viết 1 ghi chú feedback kiểu quản lý: điểm mạnh + gợi ý + hành động.
4. Nếu tenant có tác vụ Talent, mở tác vụ và map các trường với bản nháp (không submit).

17) Link tài liệu chính thức

• Tổng quan Workday HCM thường bao gồm Talent Management như một mảng cốt lõi.
• Business process framework (cách tác vụ/phê duyệt được route).

2) Dành cho ai + Khi nào nên dùng

Nhân viên dùng để xin nghỉ và xem số dư. Quản lý dùng để duyệt yêu cầu và quản lý “coverage”. HR/People cấu hình chính sách và theo dõi tuân thủ.

• Nhân viên: xin nghỉ, xem số dư/tích lũy.
• Quản lý: duyệt yêu cầu, theo dõi trùng lịch, xem dashboard (nếu bật).
• HR: định nghĩa chính sách/kế hoạch nghỉ (cấu hình tenant).
• Dùng tab này trước các mùa cao điểm nghỉ lễ để giảm xung đột.

3) Vị trí trên điều hướng + Tab liên quan

Điểm vào thường gặp: worklet/app Absence/Time Off, Search “Request Time Off”, phê duyệt trong Inbox. Liên quan: Business Processes Reporting Security.

• Nhân viên: Home → Time Off/Absence.
• Quản lý: phê duyệt trong Inbox + dashboard đội nhóm (nếu có).
• Dùng lịch (nếu tích hợp) để kiểm tra trùng lịch khi duyệt.
• Dùng báo cáo để phát hiện xu hướng và rủi ro tuân thủ.

4) Mô hình tư duy / Luồng

Các thao tác vắng mặt là luồng theo chính sách. Bạn gửi yêu cầu, Workday kiểm tra điều kiện và số dư, route phê duyệt, rồi cập nhật số dư và lịch.

1. Nhân viên gửi yêu cầu nghỉ với ngày và loại nghỉ.
2. Hệ thống kiểm tra quy tắc (số dư, điều kiện, trùng lịch).
3. Phê duyệt được route đến quản lý/vai trò theo chính sách.
4. Hoàn tất sẽ cập nhật số dư và hiển thị cho việc lập kế hoạch.

5) Đối tượng & Thuật ngữ

• Nghỉ phép (Time Off): các vắng mặt ngắn (phép năm, ốm) tuỳ chính sách.
• Nghỉ dài hạn (Leave of Absence): loại nghỉ dài hoặc theo quy định.
• Số dư (Balance): thời gian nghỉ còn lại theo tích lũy/chính sách.
• Tích lũy (Accrual): quy tắc cộng dồn ngày/giờ nghỉ.
• Phê duyệt (Approval): được route qua các bước business process.

6) Máy trạng thái / Vòng đời

• Draft → Submitted → Chờ phê duyệt → Approved/Denied.
• Yêu cầu đã duyệt có thể hủy theo chính sách.
• Hồ sơ nghỉ dài hạn có thể có bước nộp tài liệu bổ sung (tuỳ tenant).
• Trạng thái và thuật ngữ có thể khác nhau theo cấu hình tenant.

7) Các việc cốt lõi cần làm

• Gửi yêu cầu nghỉ với đúng loại và đúng ngày.
• Kiểm tra số dư và tránh xin vượt số dư.
• Quản lý xem trùng lịch và duyệt/từ chối.
• Hủy hoặc chỉnh sửa yêu cầu khi kế hoạch thay đổi.
• Báo cáo xu hướng nghỉ để lập kế hoạch (nếu bật).

8) Luồng chuẩn #1: Nhân viên xin nghỉ

Dùng khi bạn cần xin nghỉ phép hoặc một loại nghỉ mà tenant của bạn hỗ trợ.

1. Mở khu vực Absence/Time Off hoặc tìm “Request Time Off”.
2. Chọn đúng loại nghỉ (phép năm/ốm/...).
3. Nhập ngày bắt đầu/kết thúc và thông tin nghỉ nửa ngày/1 phần ngày nếu cần.
4. Xem tác động lên số dư (nếu có hiển thị).
5. Thêm ghi chú giúp quản lý hiểu bối cảnh (tuỳ chọn nhưng hữu ích).
6. Submit và đọc thông báo trạng thái.
7. Kiểm tra trạng thái yêu cầu và màn hình số dư sau đó.

9) Luồng chuẩn #2: Quản lý duyệt nghỉ

Dùng khi bạn nhận phê duyệt nghỉ trong Inbox.

1. Mở Inbox và chọn yêu cầu nghỉ.
2. Xem ngày, loại nghỉ, và ghi chú của nhân viên.
3. Kiểm tra coverage/trùng lịch đội nhóm (lịch/dashboard nếu có).
4. Xác nhận dấu hiệu tuân thủ chính sách (gợi ý số dư/điều kiện).
5. Duyệt hoặc từ chối; nếu từ chối thì nêu lý do.
6. Xác nhận hoàn tất và thông báo cho nhân viên nếu cần.

10) Điểm quyết định

11) Lỗi thường gặp (và cách tránh)

• Lỗi: Chọn sai loại nghỉ. Tránh: xác nhận định nghĩa loại nghỉ trong danh mục chính sách.
• Lỗi: Quên thiết lập nghỉ nửa ngày/1 phần ngày. Tránh: kiểm tra tuỳ chọn giờ/nửa ngày nếu áp dụng.
• Lỗi: Duyệt mà không kiểm tra trùng lịch. Tránh: xem nhanh lịch đội nhóm hoặc dashboard.
• Lỗi: Không ghi chú ngoại lệ. Tránh: thêm comment để rõ ràng cho audit.
• Lỗi: Nghĩ số dư cập nhật ngay lập tức. Tránh: kiểm tra lại sau khi phê duyệt hoàn tất.

12) Quyền hạn & Vai trò

Phê duyệt và khả năng nhìn thấy phụ thuộc vai trò bảo mật (nhân viên vs quản lý vs HR) và phạm vi tổ chức.

13) Dữ liệu & Tích hợp

Workday cung cấp dịch vụ Absence Management để truy cập thông tin nghỉ của nhân sự và gửi yêu cầu nghỉ (khả năng API tuỳ tenant).

• Dùng service/API chính thức khi tổ chức bạn hỗ trợ tích hợp.
• Đảm bảo tuân thủ bảo mật và quy tắc chia sẻ dữ liệu.
• Xác thực hành động qua API khớp với chính sách và phê duyệt trong UI.
• Ghi log và giám sát yêu cầu để audit và xử lý sự cố.

14) Thế nào là “làm tốt”

• Yêu cầu chính xác (loại/ngày) và được duyệt có bối cảnh.
• Số dư và lịch luôn nhất quán.
• Quản lý chủ động coverage nhờ công cụ hiển thị.
• Audit trail có lý do rõ ràng cho ngoại lệ/từ chối.

15) Checklist: Trước khi làm + Sau khi làm

16) Bài lab (5–15 phút)

Mục tiêu: quen tay với việc gửi yêu cầu và theo dõi trạng thái.

1. Mở màn hình số dư và ghi lại số nghỉ hiện có.
2. Bắt đầu một yêu cầu nghỉ và điền đến bước xem lại (đừng submit nếu không nên).
3. Tìm vị trí hiển thị lịch sử/trạng thái yêu cầu trong tenant của bạn.
4. Nếu bạn là quản lý, mở một mục phê duyệt và xem các dấu hiệu coverage.

17) Link tài liệu chính thức

• Khả năng Workday Absence Management (các chức năng chính và trải nghiệm).
• Workday REST API directory (danh mục dịch vụ Absence Management).

2) Dành cho ai + Khi nào nên dùng

Dành cho HRIS/security admin, HR partner, và quản lý xử lý phê duyệt hoặc dữ liệu nhạy cảm. Dùng khi quyền có vẻ “sai” hoặc khi onboarding vai trò/người dùng mới.

• HRIS/Security: cấu hình vai trò/nhóm và chính sách.
• HR/Quản lý: hiểu route phê duyệt và giới hạn truy cập.
• Nhân viên: hiểu vì sao bạn không thấy một số dữ liệu/hành động.
• Dùng sau khi đổi vai trò, chuyển tổ chức, hoặc triển khai quy trình mới.

3) Vị trí trên điều hướng + Tab liên quan

Cấu hình bảo mật thường chỉ dành cho admin thông qua các tác vụ security. Tab liên quan: Business Processes Integrations & APIs Core HCM.

• Admin dùng các tác vụ như tạo/cấu hình security groups (tên tác vụ tuỳ tenant).
• Người dùng “cảm” bảo mật qua việc họ thấy gì trên record và thấy được task nào.
• Phê duyệt phụ thuộc vai trò trong business process và cách gán phạm vi.
• Quyền API cũng theo cùng mô hình bảo mật này.

4) Mô hình tư duy / Luồng

Bảo mật = “ai + phạm vi + quyền”. Vai trò/nhóm cấp quyền, phạm vi thường định nghĩa theo tổ chức, và chính sách áp vào domain (dữ liệu) và business process (hành động/phê duyệt).

1. Gán người dùng vào security group/role.
2. Định nghĩa phạm vi (áp lên org/worker/data nào).
3. Cấp domain access (xem/sửa dữ liệu).
4. Cấp quyền theo business process policy (khởi tạo/duyệt các bước).

5) Đối tượng & Thuật ngữ

• Vai trò bảo mật (Security Role): vai trò được gán cho người dùng để thực hiện/duyệt/hỗ trợ theo phạm vi tổ chức.
• Nhóm bảo mật (Security Group): cấu trúc nhóm dùng cho phân quyền (tuỳ tenant).
• Bảo mật theo domain (Domain Security): kiểm soát quyền dữ liệu (xem/sửa).
• Chính sách business process (Business Process Policy): ai được khởi tạo/duyệt từng bước.
• Nguyên tắc tối thiểu quyền (Least Privilege): chỉ cấp đúng cái cần thiết.

6) Máy trạng thái / Vòng đời

Thay đổi bảo mật thường theo luồng: yêu cầu → phê duyệt → gán quyền → có hiệu lực (đôi khi có thời điểm/effective date). Vòng đời cụ thể tuỳ tenant.

• Requested: người dùng cần quyền do đổi vai trò.
• Approved: chủ sở hữu bảo mật xác nhận lý do.
• Assigned: áp roles/groups kèm phạm vi.
• Validated: người dùng test quyền; lỗi được chỉnh.

7) Các việc cốt lõi cần làm

• Giải thích vì sao 2 người thấy hành động khác nhau trên cùng một record.
• Yêu cầu/gán vai trò với phạm vi đúng (theo org).
• Xử lý an toàn lỗi thiếu task/nút.
• Đảm bảo phê duyệt route đến vai trò dự kiến.
• Đồng bộ quyền API/tích hợp với chính sách bảo mật.

8) Luồng chuẩn #1: Xử lý “thiếu hành động/nút”

Dùng khi ai đó nói “mình không thấy hành động mà người khác có.” Mục tiêu: tách bạch đó là vấn đề điều hướng, ngữ cảnh object, hay bảo mật.

1. Xác nhận người dùng đang ở đúng object (worker vs position vs org).
2. Xác nhận họ dùng đúng tenant/môi trường (prod vs sandbox).
3. Yêu cầu họ tìm trực tiếp tên task bằng Search để loại trừ vấn đề vị trí UI.
4. So sánh với người dùng “chuẩn”: cùng phạm vi org và cùng role không?
5. Kiểm tra hành động đó có gắn với một bước trong business process policy không.
6. Escalate lên security admin kèm chi tiết: user, object, task, org, thời điểm.

9) Luồng chuẩn #2: Onboard vai trò mới (admin)

Dùng khi một team/chức năng mới cần quyền Workday.

1. Xác định trách nhiệm và danh sách task tối thiểu cần có.
2. Ánh xạ trách nhiệm → roles/groups (ưu tiên dùng cái có sẵn).
3. Định nghĩa phạm vi (org/worker nào) cho việc gán vai trò.
4. Test với 1 người dùng pilot trên sandbox/training tenant.
5. Xác minh quyền nhìn thấy dữ liệu theo domain và quyền thực hiện task.
6. Xác minh route/phê duyệt business process với vai trò đó.
7. Rollout rộng và tài liệu hoá quy trình “request access”.

10) Điểm quyết định

11) Lỗi thường gặp (và cách tránh)

• Lỗi: Cấp quyền rộng “cho nhanh hết lỗi”. Tránh: least privilege + phạm vi đúng.
• Lỗi: Xử lý sự cố mà không có thông tin cụ thể. Tránh: ghi user, task, object, org, thời điểm.
• Lỗi: Nhầm domain security với business process security. Tránh: chẩn đoán theo câu hỏi: xem dữ liệu hay thực hiện hành động.
• Lỗi: Không test trên sandbox. Tránh: pilot và xác minh trước khi rollout.
• Lỗi: Quên rằng user tích hợp cũng cần phân quyền. Tránh: coi tích hợp như một user và cấp quyền có phạm vi.

12) Quyền hạn & Vai trò

Vai trò bảo mật cho phép người dùng xem xét, thực hiện hoặc phê duyệt tác vụ và hỗ trợ các tổ chức mà vai trò đó được gán.

• Duy trì catalog vai trò: vai trò nào dành cho công việc nào.
• Tài liệu hoá quy tắc phạm vi (role bao phủ org nào).
• Rà soát vai trò định kỳ (gỡ quyền không dùng).
• Tách nhiệm vụ (separation of duties) cho hành động nhạy cảm.

13) Dữ liệu & Tích hợp

API/service luôn áp dụng bảo mật; quyền của user tích hợp cần khớp với chính sách domain và business process.

14) Thế nào là “làm tốt”

• Người dùng chỉ có quyền cần thiết, được scope đúng.
• Phê duyệt route ổn định theo vai trò, không phụ thuộc cá nhân.
• Thay đổi bảo mật có thể audit và có lý do rõ ràng.
• Tích hợp cũng theo cùng nguyên tắc tối thiểu quyền.

15) Checklist: Trước khi làm + Sau khi làm

16) Bài lab (5–15 phút)

Mục tiêu: luyện chẩn đoán bảo mật mà không cấp quyền quá tay.

1. Chọn 1 task phổ biến (vd: duyệt nghỉ) và liệt kê vai trò cần thiết.
2. Mô phỏng case “thiếu hành động” và điền template: user/task/object/org/time.
3. Đề xuất thay đổi quyền tối thiểu (role + phạm vi) để sửa.
4. Viết kế hoạch rollback ngắn (gỡ role nếu cấp quá rộng).

17) Link tài liệu chính thức

• Tổng quan vai trò bảo mật Workday (ví dụ: tài liệu hướng dẫn cấp tổ chức).
• Business process framework (vai trò và logic route trong workflow).

2) Dành cho ai + Khi nào nên dùng

Dành cho HRIS admin, chủ sở hữu quy trình, và power users quản lý phê duyệt/workflow. Dùng khi phê duyệt gây khó hiểu, quy trình bị kẹt, hoặc bạn đang rollout giao dịch (transaction) mới.

• Admin: cấu hình bước, điều kiện và routing theo vai trò.
• Quản lý: hiểu vì sao phê duyệt route đến bạn và bạn đang duyệt cái gì.
• HR: đảm bảo các bước tuân thủ (compliance) có mặt và audit được.
• Dùng sau khi đổi chính sách (lương, nghỉ phép, tuyển dụng) làm workflow phải cập nhật.

3) Vị trí trên điều hướng + Tab liên quan

BPF thường được truy cập qua các tác vụ admin và được “trải nghiệm” qua các tác vụ trong Inbox. Tab liên quan: Security Core HCM Recruiting Absence.

• Người dùng: các item trong Inbox chính là các bước đang hoạt động của business process.
• Admin: các tác vụ cấu hình (tên tuỳ tenant) định nghĩa luật routing.
• Màn hình trạng thái/lịch sử giúp truy vết bước nào đang chờ.
• Việc gán vai trò và phạm vi org ảnh hưởng ai sẽ nhận bước.

4) Mô hình tư duy / Luồng

Hãy coi BPF là một bộ máy “nếu thế này thì làm thế kia” được kích hoạt bởi các sự kiện trong tổ chức, nơi bạn chọn luật và logic.

1. Sự kiện kích hoạt một business process (vd: bắt đầu hire).
2. Quy trình chạy các bước (review, approvals, docs, notifications).
3. Các bước được route đến vai trò dựa trên điều kiện và phạm vi tổ chức.
4. Hoàn tất sẽ cập nhật record và ghi lại audit trail.

5) Đối tượng & Thuật ngữ

• Business Process: định nghĩa workflow cho một sự kiện.
• Step: bước con trong quy trình (duyệt/review/hành động).
• Condition Rule: logic để thêm/bỏ bước dựa trên dữ liệu.
• Routing: cách công việc đi đến vai trò/người dùng.
• Notifications: thông báo/tin nhắn được kích hoạt theo bước.
• Audit Trail: lịch sử ai làm gì, khi nào.

6) Máy trạng thái / Vòng đời

Một quy trình thường đi qua các trạng thái khi các bước hoàn tất.

• Initiated: được tạo bởi sự kiện/nộp task.
• In progress: một hoặc nhiều bước đang chờ trong Inbox.
• On hold: bị chặn do thiếu dữ liệu hoặc phụ thuộc bên ngoài (tuỳ tenant).
• Completed: mọi bước bắt buộc xong; cập nhật record được áp dụng.
• Cancelled/Denied: dừng; kết quả phụ thuộc cấu hình.

7) Các việc cốt lõi cần làm

• Truy vết vì sao một quy trình route đến một approver cụ thể.
• Xác định quy trình đang kẹt ở đâu và ai sở hữu bước tiếp theo.
• Thiết kế điều kiện để route theo org/số tiền/loại giao dịch.
• Đảm bảo tách nhiệm vụ (separation of duties) cho hành động nhạy cảm.
• Cải thiện trải nghiệm người dùng bằng cách giảm bước không cần thiết.

8) Luồng chuẩn #1: Truy vết quy trình bị kẹt (power user)

Dùng khi một yêu cầu “pending mãi không xong”. Mục tiêu: xác định người/vai trò đang giữ bước và input còn thiếu.

1. Mở record của yêu cầu đã nộp (hoặc dùng Search để tìm).
2. Tìm màn hình trạng thái/lịch sử quy trình (nếu tenant bật).
3. Xác định bước đang chờ và vai trò/người được gán.
4. Kiểm tra thiếu file đính kèm/field hoặc lỗi validation.
5. Nhắn cho owner với ngữ cảnh rõ: cái gì, vì sao, hạn xử lý.
6. Nếu routing có vẻ sai, escalte cho admin kèm bằng chứng.

9) Luồng chuẩn #2: Giảm “ồn” phê duyệt (admin)

Dùng khi người dùng than “quá nhiều approval”. Mục tiêu: giữ kiểm soát nhưng giảm ma sát không cần thiết.

1. Chọn một business process (vd: nghỉ phép, hire, đổi lương).
2. Liệt kê các kiểm soát/compliance bắt buộc phải giữ.
3. Rà soát điều kiện của các bước: bước nào đang kích hoạt quá thường xuyên?
4. Chỉnh điều kiện routing để chỉ nhắm đúng case liên quan.
5. Test trên sandbox với kịch bản thực tế (so sánh A/B).
6. Rollout và theo dõi thời gian hoàn tất + tỉ lệ lỗi.

10) Điểm quyết định

11) Lỗi thường gặp (và cách tránh)

• Lỗi: Hard-code cá nhân trong routing. Tránh: route theo role kèm phạm vi org.
• Lỗi: Duyệt quá nhiều thứ. Tránh: thêm điều kiện để bước chỉ chạy khi cần.
• Lỗi: Không pilot test. Tránh: test sandbox với cả edge cases.
• Lỗi: Bỏ kiểm soát để nhanh hơn. Tránh: giữ compliance; tối ưu điều kiện thay vì xoá bước.
• Lỗi: Hướng dẫn người dùng kém. Tránh: thêm instruction/checklist ở các bước hay sai.

12) Quyền hạn & Vai trò

Các bước BPF route dựa trên vai trò và bảo mật; cấu hình đúng phụ thuộc vào việc gán vai trò và chính sách truy cập.

13) Dữ liệu & Tích hợp

Tích hợp thường kích hoạt hoặc phụ thuộc business process; cần đồng bộ hành động service/API với phê duyệt workflow để tránh bypass kiểm soát.

14) Thế nào là “làm tốt”

• Người dùng hiểu vì sao có phê duyệt và họ đang duyệt gì.
• Quy trình hiếm khi bị kẹt; owner rõ ràng.
• Routing theo vai trò có backup, không phụ thuộc cá nhân.
• Audit trail đầy đủ và hỗ trợ tuân thủ.

15) Checklist: Trước khi làm + Sau khi làm

16) Bài lab (5–15 phút)

Mục tiêu: luyện mô tả một thay đổi workflow thật rõ ràng.

1. Chọn 1 quy trình bạn hay gặp trong Inbox (nghỉ phép, hire, change request).
2. Viết các bước của nó thành 6–8 gạch đầu dòng (ai làm gì, theo thứ tự).
3. Xác định 2 điểm đau (delay, khó hiểu, làm lại).
4. Đề xuất 1 cải tiến theo điều kiện và 1 cải tiến theo hướng dẫn.

17) Link tài liệu chính thức

• Datasheet Business Process Framework của Workday (tổng quan chính thức).
• PDF “HCM can do what” có nhắc tới business processes linh hoạt và trực quan hoá workflow.

2) Dành cho ai + Khi nào nên dùng

Quản lý dùng reporting để xem chỉ số team; HR dùng cho tuân thủ và lập kế hoạch; lãnh đạo dùng cho quyết định workforce. Dùng khi lập kế hoạch, theo dõi hoàn thành chu kỳ, hoặc kiểm tra sau thay đổi.

• Manager: headcount, xu hướng nghỉ phép, theo dõi thay đổi team.
• HR: funnel tuyển dụng, tuân thủ chính sách, audit chất lượng dữ liệu.
• Lãnh đạo: chỉ báo và xu hướng kế hoạch lực lượng lao động.
• Dùng sau các thay đổi lớn (tái cơ cấu, đẩy tuyển dụng, cập nhật chính sách).

3) Vị trí trên điều hướng + Tab liên quan

Điểm vào thường gặp: worklet/app Reports, Search theo tên báo cáo, dashboards (tuỳ tenant). Liên quan: Core HCM Absence Business Processes Security.

• Dùng Search với từ khoá như “Headcount”, “Time Off”, “Hiring”.
• Lưu bộ lọc (nếu được phép) để báo cáo lặp lại.
• Ưu tiên dashboards cho các buổi review định kỳ (nếu bật).
• Xuất file cẩn thận và lưu/chia sẻ an toàn theo chính sách.

4) Mô hình tư duy / Luồng

Báo cáo là lớp “đọc” trên dữ liệu đã được quản trị. Giao dịch (transactions) thay đổi dữ liệu thông qua business processes; báo cáo đo lường/giám sát kết quả.

1. Xác định câu hỏi (quyết định nào sẽ dựa vào báo cáo này?).
2. Chọn đúng báo cáo và áp bộ lọc phạm vi (scope).
3. Kiểm chứng độ chính xác bằng spot-check và tổng số.
4. Hành động theo phát hiện (tác vụ follow-up, phê duyệt, hành động kế hoạch).

5) Đối tượng & Thuật ngữ

• Report: đầu ra có cấu trúc dựa trên nguồn dữ liệu (tuỳ tenant).
• Dashboard: tập chỉ số được “curate” (tuỳ tenant).
• Prompt/Filter: tham số để giới hạn đầu ra báo cáo.
• Export: trích xuất ra file; làm tăng rủi ro rò rỉ dữ liệu.
• Security: kiểm soát dữ liệu nào xuất hiện trong báo cáo.

6) Máy trạng thái / Vòng đời

Không áp dụng cho tool/tab này (báo cáo không có vòng đời chung trong nguồn chính thức công khai; phụ thuộc tenant).

7) Các việc cốt lõi cần làm

• Chạy báo cáo headcount hoặc org với đúng phạm vi.
• Theo dõi mức độ hoàn thành của một quy trình/chu kỳ (tuyển dụng, duyệt nghỉ phép).
• Phát hiện bất thường (thiếu dữ liệu, xu hướng lạ).
• Xuất và chia sẻ an toàn (chỉ người nhận được phép).
• Cung cấp bằng chứng cho audit/tuân thủ (khi cần).

8) Luồng chuẩn #1: Chạy báo cáo team có phạm vi (manager)

Dùng khi bạn cần thông tin team chính xác nhanh.

1. Search một báo cáo team/org (vd: “My Team”, “Headcount”).
2. Xác nhận prompt phạm vi khớp supervisory org của bạn.
3. Áp bộ lọc ngày/effective nếu báo cáo hỗ trợ.
4. Kiểm tra tổng số và rà nhanh các outlier rõ ràng.
5. Spot-check 2–3 dòng so với hồ sơ worker.
6. Chỉ export khi cần; lưu trữ an toàn theo chính sách.

9) Luồng chuẩn #2: Theo dõi kết quả workflow (HR/ops)

Dùng khi bạn cần đảm bảo quy trình đang chạy (vd: duyệt nghỉ phép hoặc các bước tuyển dụng).

1. Chọn một chỉ số quy trình (pending approvals, aged requests).
2. Chạy report/dashboard liên quan (tuỳ tenant).
3. Lọc theo “pending” và sort theo tuổi/ưu tiên.
4. Xác định owner (role/user) của bước tiếp theo.
5. Gửi nhắc nhở có mục tiêu kèm ngữ cảnh và hạn xử lý.
6. Chạy lại báo cáo để xác nhận backlog giảm.

10) Điểm quyết định

11) Lỗi thường gặp (và cách tránh)

• Lỗi: Chạy báo cáo với prompt mặc định. Tránh: đặt scope có chủ đích.
• Lỗi: Coi file export là “source of truth”. Tránh: Workday là system of record; cần dữ liệu mới thì chạy lại.
• Lỗi: Chia sẻ dữ liệu nhạy cảm quá rộng. Tránh: tuân thủ security và least-privilege.
• Lỗi: Không kiểm chứng các điểm bất thường. Tránh: spot-check với worker records.
• Lỗi: Nhầm giao dịch với báo cáo. Tránh: chỉnh sửa phải qua tasks + business processes.

12) Quyền hạn & Vai trò

Khả năng xem báo cáo bị chi phối bởi security roles và phạm vi. Nếu bạn không thấy báo cáo, có thể là vấn đề quyền chứ không phải thiếu tính năng.

13) Dữ liệu & Tích hợp

Nếu tổ chức dùng API để kéo số liệu, hãy bám service catalog chính thức và quy tắc security.

14) Thế nào là “làm tốt”

• Báo cáo lặp lại được (saved prompts) và đã được kiểm chứng.
• Quyết định tham chiếu phạm vi và effective dates rõ ràng.
• Chia sẻ dữ liệu đúng quyền và giảm lộ lọt tối đa.
• Reporting kéo theo hành động (không chỉ chụp màn hình).

15) Checklist: Trước khi làm + Sau khi làm

16) Bài lab (5–15 phút)

Mục tiêu: luyện reporting an toàn kèm kiểm chứng.

1. Chọn một báo cáo bạn truy cập được (vd: “My Team”).
2. Chạy với 2 scope khác nhau và so sánh kết quả.
3. Spot-check 3 dòng so với worker profiles.
4. Viết 1 đoạn tóm tắt: phạm vi, phát hiện, hành động.

17) Link tài liệu chính thức

• Tổng quan Workday HCM có nhắc tới workforce planning & analytics như một mảng sản phẩm.
• Cách Workday mô tả hành trình nhân viên end-to-end (plan to hire → retire).

2) Dành cho ai + Khi nào nên dùng

Dành cho dev tích hợp, HRIS, và chủ sở hữu nền tảng/bảo mật. Dùng khi bạn cần kéo dữ liệu, đẩy yêu cầu (như xin nghỉ), hoặc tích hợp công cụ bên thứ ba.

• Developer: gọi API và xử lý lỗi.
• HRIS: đảm bảo quản trị dữ liệu và đồng bộ với business processes.
• Security: áp least privilege cho user tích hợp.
• Dùng trước khi bắt đầu tích hợp mới để xác nhận service có tồn tại/khả dụng.

3) Vị trí trên điều hướng + Tab liên quan

REST Directory chính thức là danh mục dịch vụ truy cập công khai; nhưng tenant cấu hình sẽ quyết định bạn dùng được gì thực sự. Liên quan: Security Business Processes Absence Reporting.

• Bắt đầu từ directory để tìm đúng service domain.
• Xác nhận service khớp module (vd: Absence Management).
• Xác nhận cách auth/authorization trong tổ chức (tuỳ tenant).
• Đồng bộ hành động API với luồng phê duyệt business process (không bypass policy).

4) Mô hình tư duy / Luồng

Một tích hợp an toàn là một “sản phẩm”: xác định kết quả, map vào services, ép bảo mật, test, và giám sát. Service có thể cho phép đọc dữ liệu và trong một số trường hợp cho phép gửi request tương tự thao tác UI.

1. Xác định use-case nghiệp vụ và các đối tượng cần thiết.
2. Tìm đúng Workday service trong REST Directory.
3. Thiết kế auth/bảo mật cho integration user (least privilege).
4. Triển khai + test trên sandbox, rồi giám sát ở production.

5) Đối tượng & Thuật ngữ

• Service: một mảng chức năng API (vd: Absence Management).
• Endpoint: URL/phương thức cụ thể cho một thao tác.
• Integration User: tài khoản không phải người dùng thật để truy cập API.
• Scope/Permissions: dữ liệu và hành động được phép.
• Monitoring: log, retry, cảnh báo, và audit.
• Directory: danh mục chính thức các REST services.

6) Máy trạng thái / Vòng đời

Tích hợp nên có vòng đời như mọi thành phần hệ thống.

• Thiết kế → Triển khai → Kiểm thử → Phát hành → Giám sát → Cải tiến.
• Cần lên kế hoạch versioning và tương thích ngược.
• Lỗi cần xử lý bằng retry và cơ chế dead-letter.
• Vòng đời/versioning API cụ thể phụ thuộc tenant và lịch phát hành của Workday.

7) Các việc cốt lõi cần làm

• Tìm đúng service cho nhu cầu domain (absence, worker, ...).
• Xác nhận thao tác hỗ trợ (đọc vs gửi request).
• Thiết kế truy cập an toàn cho integration user.
• Xây xử lý lỗi và giám sát vững.
• Đáp ứng yêu cầu tuân thủ/audit.

8) Luồng chuẩn #1: Tìm service và xác nhận phù hợp

Dùng khi bạn bắt đầu tích hợp và cần xác nhận Workday có hỗ trợ không.

1. Mở REST Directory và tìm theo domain (vd: “Absence”).
2. Đọc mô tả service để xác nhận hành động hỗ trợ.
3. Liệt kê object/field cần dùng và map vào khái niệm của service.
4. Xác định rủi ro bảo mật (dữ liệu nhạy cảm, phê duyệt).
5. Xác nhận với HRIS/admin rằng service được bật/có thể dùng trong tenant.
6. Viết API contract: input, output, lỗi, kỳ vọng audit.

9) Luồng chuẩn #2: Tích hợp “xin nghỉ” (ví dụ)

Chỉ là ví dụ: bám theo cách làm được duyệt trong tenant của bạn. Mục tiêu: gửi request qua service chính thức mà không bypass policy.

1. Xác nhận tenant cho phép tạo yêu cầu nghỉ phép qua API.
2. Tạo/gán integration user với least privilege.
3. Dùng service Absence Management để gửi thao tác tạo request.
4. Đảm bảo workflow phê duyệt chạy như trên UI (nếu áp dụng).
5. Ghi log request ID/status và trả về cho hệ thống gọi.
6. Xử lý lỗi bằng retry và cơ chế idempotency.
7. Giám sát kết quả và đối soát trạng thái định kỳ.

10) Điểm quyết định

11) Lỗi thường gặp (và cách tránh)

• Lỗi: Coi integration user như admin. Tránh: least privilege và role có phạm vi rõ ràng.
• Lỗi: Bypass phê duyệt. Tránh: đồng bộ hành động API với business processes và policy.
• Lỗi: Không có idempotency. Tránh: thiết kế tránh tạo trùng khi retry.
• Lỗi: Monitoring yếu. Tránh: cảnh báo, dashboard, và cơ chế đối soát.
• Lỗi: Không kéo HRIS/security vào sớm. Tránh: đồng thiết kế security và data governance.

12) Quyền hạn & Vai trò

Truy cập API nên được quản trị bằng security roles/groups như mọi user. Integration user chỉ nên có domain và process permissions cần thiết.

13) Dữ liệu & Tích hợp

REST Directory liệt kê rõ các services, bao gồm năng lực của Absence Management như truy cập chi tiết nghỉ phép và gửi yêu cầu nghỉ/leave.

• Dùng mô tả trong directory để map tính năng vào services.
• Xác nhận tenant enablement và cách xác thực.
• Tài liệu hoá phân loại dữ liệu và đối tượng được phép dùng.
• Thiết lập retention và audit logging cho các API calls.

14) Thế nào là “làm tốt”

• Tích hợp bền bỉ (retry, idempotency, monitoring).
• Bảo mật tối thiểu và có phạm vi; không lộ dữ liệu ngoài ý muốn.
• Tôn trọng phê duyệt/chính sách; audit trail rõ ràng.
• Có chủ sở hữu và runbook xử lý sự cố.

15) Checklist: Trước khi làm + Sau khi làm

16) Bài lab (5–15 phút)

Mục tiêu: luyện map yêu cầu vào service contract.

1. Chọn 1 nhu cầu: “xin nghỉ” hoặc “kéo số dư nghỉ phép”.
2. Tìm service liên quan trong REST Directory và chép các mô tả năng lực chính vào ghi chú.
3. Soạn API contract: input, output, lỗi, trường audit.
4. Liệt kê quyền tối thiểu bạn nghĩ là cần.

17) Link tài liệu chính thức

• Workday REST Directory (danh mục chính thức các REST services).
• Năng lực Workday Absence Management (tổng quan sản phẩm).

2) Dành cho ai + Khi nào nên dùng

Dành cho nhân viên và quản lý cần xử lý nhanh khi không ngồi desktop. Dùng cho tác vụ thường ngày, không dùng cho cấu hình phức tạp hoặc thay đổi rủi ro cao.

• Nhân viên: xin nghỉ, cập nhật liên hệ (nếu được phép).
• Quản lý: duyệt nghỉ/duyệt bước tuyển dụng (nếu được phép).
• Dùng khi đi công tác/di chuyển hoặc cần duyệt nhanh.
• Chuyển sang desktop khi cần xem kỹ, xử lý file đính kèm, hoặc kiểm tra dữ liệu lớn.

3) Vị trí trên điều hướng + Tab liên quan

Mobile thường phản chiếu các worklets chính và Inbox. Liên quan: Overview Absence Security.

• Bắt đầu: Inbox cho tác vụ/phê duyệt.
• Dùng Search (nếu có) để tìm tác vụ.
• Dùng khu vực Time Off/Absence để xin nghỉ và xem số dư.
• Dùng trang hồ sơ/self-service để cập nhật các mục được phép.

4) Mô hình tư duy / Luồng

Mobile phù hợp cho workflow ngắn: mở tác vụ → kiểm tra trường quan trọng → phê duyệt/gửi → xác nhận trạng thái. Các kiểm tra phức tạp nên làm trên desktop.

1. Mở item trong Inbox hoặc bắt đầu một yêu cầu đơn giản.
2. Kiểm tra các điểm cốt lõi (ngày, người, loại, số tiền nếu có).
3. Thực hiện (Approve/Submit) và thêm comment ngắn nếu cần.
4. Xác nhận trạng thái và các tác vụ follow-up.

5) Đối tượng & Thuật ngữ

• Inbox: hàng đợi tác vụ/phê duyệt.
• Notifications: nhắc nhở hành động hoặc cần xem.
• Self-service: các thay đổi nhân viên được phép tự làm.
• Bảo mật mobile: khoá máy, lưu trữ an toàn, timeout phiên (theo chính sách công ty).
• Yêu cầu nghỉ phép: workflow phổ biến trên mobile.

6) Máy trạng thái / Vòng đời

Không áp dụng cho tool/tab này (UX mobile thay đổi theo tenant và thiết bị; nguồn chính thức công khai trong lần chạy này không định nghĩa một vòng đời mobile chuẩn chung).

7) Các việc cốt lõi cần làm

• Duyệt/từ chối một item trong Inbox nhanh.
• Xin nghỉ và kiểm tra số dư.
• Xem thông tin hồ sơ cá nhân và trạng thái yêu cầu.
• Nhận thông báo và xử lý trước hạn.
• Chuyển vấn đề phức tạp sang desktop/support.

8) Luồng chuẩn #1: Duyệt trên mobile (quản lý)

Dùng khi bạn cần duyệt nghỉ phép hoặc các phê duyệt routine tương tự.

1. Mở Inbox trên mobile.
2. Chọn item phê duyệt và mở chi tiết.
3. Kiểm tra trường chính (ngày/loại/người/ghi chú).
4. Kiểm tra trùng lịch/coverage nếu thấy (không thấy thì chuyển desktop).
5. Approve hoặc Deny và thêm comment ngắn nếu cần.
6. Xác nhận trạng thái hoàn tất.

9) Luồng chuẩn #2: Xin nghỉ (nhân viên)

Dùng khi bạn cần tạo yêu cầu nghỉ nhanh.

1. Mở khu vực Time Off/Absence.
2. Chọn loại nghỉ và ngày.
3. Xem tác động lên số dư (nếu có hiển thị).
4. Thêm ghi chú để quản lý có ngữ cảnh.
5. Submit và xác nhận trạng thái.
6. Xem lại lịch sử/trạng thái yêu cầu sau.

10) Điểm quyết định

11) Lỗi thường gặp (và cách tránh)

• Lỗi: Duyệt việc phức tạp trên màn hình nhỏ. Tránh: chuyển desktop cho phê duyệt rủi ro cao.
• Lỗi: Dùng mobile mà không khoá thiết bị. Tránh: bật khoá mạnh và theo chính sách công ty.
• Lỗi: Bỏ qua xác nhận trạng thái. Tránh: luôn kiểm tra đã submit/approve thành công.
• Lỗi: Duyệt nhầm người/yêu cầu. Tránh: kiểm tra lại tên/đối tượng trước khi duyệt.
• Lỗi: Lưu export/screenshot. Tránh: tránh chụp/lưu dữ liệu nhạy cảm trên thiết bị.

12) Quyền hạn & Vai trò

Trên mobile, dữ liệu hiển thị vẫn phụ thuộc cùng security roles và scope như desktop.

13) Dữ liệu & Tích hợp

Không áp dụng cho tool/tab này (chi tiết tích hợp mobile tuỳ tenant; không được nêu rõ trong nguồn chính thức công khai của lần chạy này).

14) Thế nào là “làm tốt”

• Tác vụ thường ngày được xử lý nhanh và đúng trên mobile.
• Hành động rủi ro cao được chuyển sang desktop để xem kỹ.
• Người dùng giữ vệ sinh bảo mật (khoá máy, đăng xuất, giảm lộ dữ liệu).
• Luôn xác nhận trạng thái và bước tiếp theo.

15) Checklist: Trước khi làm + Sau khi làm

16) Bài lab (5–15 phút)

Mục tiêu: xây thói quen mobile an toàn.

1. Mở Inbox và chọn 1 tác vụ rủi ro thấp có thể xử lý trên mobile.
2. Tìm Time Off/Absence và xác định chỗ xem số dư/trạng thái.
3. Viết “mobile safe list” (3 hành động) và “desktop only list” (3 hành động).
4. Xác nhận bạn tìm được link help/support trong app (nếu có).

17) Link tài liệu chính thức

• Workday Absence Management nhấn mạnh mobile self-service là một năng lực quan trọng.