ทําให้วงจรชีวิตของใบสั่งบริการและการกํากับดูแล SLA เป็นอัตโนมัติด้วย Power Platform

สามารถใช้ Power Platform เพื่อสร้างโซลูชันที่ทําให้วงจรชีวิตของใบสั่งบริการเป็นแบบอัตโนมัติ วิธีนี้ทําให้การสร้างคําขอใบสั่งบริการ จัดการเวิร์กโฟลว์การอนุมัติในหลายลําดับขั้น บังคับใช้การจัดการวงจรชีวิต SLA และจัดการกระบวนการเลิกจ้าง นอกจากนี้ยังเป็นระบบส่วนกลางสําหรับทีมฝ่ายกฎหมายและผู้รับเหมาในการจัดการสัญญาบริการและเอกสารที่ลงนามที่เกี่ยวข้อง

แผนภาพสถาปัตยกรรม

เวิร์กโฟลว์

เวิร์กโฟลว์ประกอบด้วยกระบวนการหลักสามกระบวนการ: เวิร์กโฟลว์ใบสั่งบริการ เวิร์กโฟลว์ SLA และเวิร์กโฟลว์การสิ้นสุด แต่ละเวิร์กโฟลว์มีลําดับขั้นและกระบวนการอนุมัติที่แตกต่างกัน

กระบวนการทำงานของใบสั่งบริการ

ผู้ใช้เริ่มต้นกระบวนการร้องขอใบสั่งบริการ โดยการกรอกฟอร์มในแอปแบบจําลองข้อมูล ผู้ใช้รายอื่น เช่น ผู้ใช้กลุ่มที่รับผิดชอบเชิงพาณิชย์และผู้ใช้ที่รับผิดชอบหลัก จะมีส่วนร่วมในกระบวนการอนุมัติในขั้นตอนที่แตกต่างกัน

เวิร์กโฟลว์มีดังนี้:

1. ผู้ใช้เข้าถึงโฮมเพจ ซึ่งเป็นหน้าแบบกําหนดเองที่ฝังอยู่ในแอปแบบจําลองข้อมูล หน้าแบบกําหนดเองมีลิงก์ด่วนไปยัง:

   • เข้าถึงใบสั่งบริการ ข้อตกลงระดับบริการ (SLA) หรือคําขอการสิ้นสุดที่มีอยู่
   • สร้างคําขอใหม่สําหรับใบสั่งบริการ SLA หรือการสิ้นสุด
   • ดูงานที่กําหนด
   • ปุ่มผู้ดูแลระบบสามารถมองเห็นได้สําหรับสมาชิกกลุ่มผู้ดูแลระบบ

2. ผู้ใช้เลือก ใบสั่งบริการใหม่ จากโฮมเพจ แบบฟอร์มใบสั่งบริการใหม่จะปรากฏขึ้นพร้อมแท็บต่างๆ เพื่อป้อนรายละเอียดใบสั่งบริการ ผู้ใช้สามารถแนบเอกสารกับใบสั่งบริการที่สร้างขึ้นใหม่โดยใช้ตัวเลือก SharePoint ตารางย่อยที่มีอยู่ภายใน

3. เมื่อต้องสร้างคําขอใบสั่งบริการ ผู้ใช้เลือกปุ่ม ส่งคําขอ แบบกําหนดเองที่ด้านบนของหน้า การดําเนินการต่อไปนี้เกิดขึ้น:

   1. ใบสั่งบริการใหม่จะถูกสร้างขึ้นด้วยรหัสใบสั่งบริการใหม่

   2. สถานะของคำขอเปลี่ยนเป็น ใบสั่งบริการที่ร้องขอ

   3. งานใหม่จะถูกสร้างขึ้นในตารางงาน และกําหนดให้กับทีมเจ้าของสําหรับกลุ่มที่รับผิดชอบเชิงพาณิชย์

   4. ผู้ใช้ไม่สามารถแก้ไขคําขอได้

   5. โฟลว์กระบวนการทางธุรกิจจะอัปเดตไปยังลําดับขั้นถัดไป

   เมื่อผู้ใช้เลือกปุ่มแบบกําหนดเอง สคริปต์จะทํางานเพื่อปรับปรุงสถานะคําขอและทริกเกอร์โฟลว์ Power Automate ที่ทํางานทั้งหมดก่อนหน้า สคริปต์บนฟอร์มของแอปแบบจําลองตรวจสอบสถานะคําขอและผู้ใช้ที่กําหนด เขตข้อมูลจะถูกเปลี่ยนเป็นแบบอ่านอย่างเดียวสำหรับทุกคน ยกเว้นกลุ่มผู้รับผิดชอบด้านการค้า เงื่อนไขนี้นําไปใช้กับปุ่มแบบกําหนดเองทั้งหมดที่พร้อมใช้งานในขั้นตอนต่าง ๆ

ผู้ใช้ที่รับผิดชอบเชิงพาณิชย์จะมอบหมายหรือปฏิเสธคําขอดังต่อไปนี้:

1. ผู้ใช้ที่รับผิดชอบเชิงพาณิชย์จะลงชื่อเข้าใช้และเลือกงานที่ได้รับมอบหมายภายใต้ งานของฉัน

2. ผู้ใช้ที่รับผิดชอบเชิงพาณิชย์จะตรวจทานคําขอ และอนุมัติหรือปฏิเสธคําขอโดยการเลือกปุ่มแบบกําหนดเองที่สอดคล้องกัน:

   • กําหนดผู้รับผิดชอบหลัก
   • ปฏิเสธคําขอ

3. ในการปฏิเสธ คําขอถูกปฏิเสธและการแจ้งเตือนจะถูกส่งไปยังผู้ร้องขอใบสั่งบริการ

4. เมื่อผู้ใช้เลือกกําหนดผู้ รับผิดชอบหลัก คําขอจะย้ายไปยังขั้นตอนถัดไป

   1. สถานะคําขอจะอัปเดตเป็นรอการอนุมัติ PR

   2. การอัปเดตของขั้นตอนในโฟลว์กระบวนการธุรกิจ

   3. งานใหม่จะถูกสร้างขึ้นสําหรับผู้ใช้ที่รับผิดชอบหลัก งานก่อนหน้านี้ที่กําหนดให้กับผู้ใช้ที่รับผิดชอบเชิงพาณิชย์จะเสร็จสมบูรณ์แล้ว

   4. การแจ้งเตือนจะถูกส่งไปยังผู้ใช้ที่รับผิดชอบหลัก

ผู้ใช้ที่รับผิดชอบหลักจะอนุมัติ ปฏิเสธ หรือร้องขอการเปลี่ยนแปลงดังต่อไปนี้:

1. ผู้ใช้ที่รับผิดชอบหลักจะลงชื่อเข้าใช้ และเลือกงานที่กําหนดภายใต้ งานของฉัน

2. ผู้ใช้ที่รับผิดชอบหลักเลือกที่จะอนุมัติปฏิเสธ หรือส่งสําหรับการแก้ไข ปุ่มแบบกําหนดเองเหล่านี้จะมองเห็นได้เฉพาะผู้ใช้ที่ได้รับมอบหมาย PR ไปยังคําขอเมื่อคําขอมีสถานะ รอการอนุมัติจาก PR เท่านั้น

   • อนุมัติ:

     1. สถานะคําขอถูกทําเครื่องหมายเป็นอนุมัติแล้ว การเปลี่ยนแปลงสถานะนี้จะดําเนินการผ่านสคริปต์แบบกําหนดเองที่เขียนบนปุ่มแบบกําหนดเอง

     2. การแจ้งเตือนจะถูกส่งไปยังกลุ่มที่รับผิดชอบเชิงพาณิชย์และผู้ร้องขอใบสั่งบริการ

     3. สถานะการร้องขอจะอัปเดตเป็นกระบวนการรับรองขั้นสุดท้ายที่ค้างอยู่

     4. งานถูกกําหนดให้กับกลุ่มผู้รับผิดชอบเชิงพาณิชย์

     5. โฟลว์กระบวนการทางธุรกิจจะอัปเดตไปยังลําดับขั้นถัดไป

     6. งานของผู้ใช้ที่รับผิดชอบหลักเสร็จสมบูรณ์แล้ว

   • ปฏิเสธ:

     1. คําขอถูกทําเครื่องหมายเป็นปฏิเสธ

     2. กระบวนการทางธุรกิจได้รับการอัปเดตไปยังระยะที่ถูกปฏิเสธ

     3. การแจ้งเตือนจะถูกส่งไปยังผู้ร้องขอใบสั่งบริการและกลุ่มที่รับผิดชอบเชิงพาณิชย์

   • ส่งเพื่อแก้ไข:

     1. คําขอจะถูกส่งไปยังผู้ร้องขอใบสั่งบริการสําหรับการแก้ไข

     2. สถานะคําขอถูกอัปเดตเป็นลําดับขั้นการร้องขอใบสั่งบริการ

     3. มีการอัปเดตโฟลว์กระบวนการทางธุรกิจในระยะเริ่มต้น

     4. การแจ้งเตือนทางอีเมลจะถูกส่งไปยังผู้ร้องขอใบสั่งบริการที่มีลิงก์ไปยังคําขอใบสั่งบริการ

   เมื่อผู้ใช้ที่รับผิดชอบหลักปฏิเสธหรืออนุมัติคําขอ เอกสาร PDF จะถูกส่งออกและบันทึกไปยัง SharePoint library ใบสั่งบริการ PDF ถูกสร้างขึ้นโดยใช้คุณลักษณะแม่แบบเอกสารของ Dataverse ที่ผู้ใช้สร้างแม่แบบใน Word โดยใช้แอตทริบิวต์เอนทิตี XML โฟลว์ Power Automate เรียกใช้ API เทมเพลตเอกสาร PDF เพื่อสร้างเวอร์ชัน PDF และส่งออกข้อมูลทั้งหมดของคําขอบริการ ID เทมเพลตของเอกสารและรหัสเฉพาะสากล (GUID) ของใบสั่งบริการจะถูกส่งผ่านไปยังโฟลว์ Power Automate

ในขั้นตอนการลงนามขั้นสุดท้าย ผู้ใช้ที่รับผิดชอบเชิงพาณิชย์จะลงนามในเอกสารและทําการร้องขอให้เสร็จสมบูรณ์ ผู้ใช้สามารถดูได้เฉพาะแท็บที่เกี่ยวข้องกับกระบวนการลงนามเอกสารเท่านั้น แท็บอื่นๆ ทั้งหมดถูกซ่อนไว้ ฟังก์ชันนี้ถูกนํามาใช้โดยใช้ XRM API และ JavaScript บนฟอร์ม

1. ในแท็บแรก ผู้ใช้ที่รับผิดชอบเชิงพาณิชย์จะเห็นปุ่ม อัปโหลดเอกสารที่ลงชื่อ

2. เมื่อผู้ใช้เลือกปุ่ม แอปจะไฮไลต์แท็บถัดไป ซึ่งประกอบด้วยตารางย่อยของเอกสาร SharePoint และเอกสาร PDF ที่สร้างขึ้นในขั้นตอนก่อนหน้า

3. ผู้ใช้ที่รับผิดชอบเชิงพาณิชย์จะดาวน์โหลดเอกสาร PDF ลงชื่อด้วยตนเอง และอัปโหลดลงในแท็บไลบรารีเอกสาร

4. ปุ่มแบบกําหนดเอง ของกระบวนการลงชื่อเสร็จสมบูรณ์ ที่ด้านบนจะพร้อมใช้งาน

5. เมื่อผู้ใช้ที่รับผิดชอบเชิงพาณิชย์เลือกปุ่ม คําขอจะกลายเป็นแบบอ่านอย่างเดียว

6. เมื่อคําขอเสร็จสมบูรณ์ การแจ้งเตือนจะถูกส่งไปยังผู้ใช้ กลุ่มผู้รับผิดชอบเชิงพาณิชย์ และผู้ใช้ที่รับผิดชอบหลัก โฟลว์จาก Power Automate ระบุสถานะของกระบวนการทางธุรกิจและงานที่ได้รับมอบหมายว่าเสร็จสมบูรณ์แล้ว

เวิร์กโฟลว์ SLA

เวิร์กโฟลว์ข้อตกลงระดับบริการ (SLA) จะเริ่มต้นหลังจากอนุมัติคําขอใบสั่งบริการแล้ว คําขอ SLA มีเวิร์กโฟลว์คล้ายกับคําขอใบสั่งบริการ ที่มีลําดับขั้นการอนุมัติและการกําหนดงาน

SLA มีอายุ 18 เดือนตามค่าเริ่มต้น และงาน backend ของ Power Automate จะทํางานทุกวันเพื่อตรวจสอบการหมดอายุของ SLA เมื่อวันหมดอายุของ SLA ตรงกับวันที่ปัจจุบัน งานจะทําเครื่องหมาย SLA และใบสั่งบริการที่เกี่ยวข้องเป็นสิ้นสุดและอัปเดตการแจ้งเตือนอีเมลที่สอดคล้องกันและลําดับขั้นของลําดับงานของกระบวนการทางธุรกิจสําหรับทั้งสองเอนทิตี

เมื่อต้องเริ่มเวิร์กโฟลว์ SLA ผู้ใช้เลือกสร้างคําขอ SLA ใหม่เพื่อเปิดฟอร์ม SLA ใหม่ ในแบบฟอร์มนี้ ผู้ใช้สามารถเลือกเฉพาะคําขอใบสั่งบริการที่เสร็จสมบูรณ์และสร้างด้วยตนเอง

เวิร์กโฟลว์การสิ้นสุดการจ้างงาน

เมื่อใบสั่งบริการและคําขอ SLA ต้องการการสิ้นสุดการทํางานที่ชัดเจน จะมีการสร้างคําขอการสิ้นสุดการทํางาน คําขอสิ้นสุดใช้เวิร์กโฟลว์ที่คล้ายกันเพื่อรับการอนุมัติจากกลุ่มที่รับผิดชอบเชิงพาณิชย์และผู้ใช้ที่รับผิดชอบหลัก

ผู้ใช้สามารถส่งคำขอการสิ้นสุดสำหรับข้อตกลงการบริการ (SLA) หรือคำสั่งบริการที่พวกเขาอนุมัติและสร้างขึ้นเท่านั้น

เมื่อถึงวันที่สิ้นสุดสำหรับคำขอการสิ้นสุดที่ได้รับอนุมัติแล้ว โฟลว์ Power Automate สำหรับแบ็คเอนด์จะทำงานทุกวันเพื่อตรวจสอบและ:

• หากคําขอมีไว้สำหรับ SLA ให้ยกเลิก SLA ที่เชื่อมโยงกับคําขอการสิ้นสุด

• ถ้าคําขอเป็นคําขอสําหรับใบสั่งบริการ ให้ยุติ SLA ทั้งหมดที่เกี่ยวข้องกับใบสั่งบริการและยุติใบสั่งบริการ

ใช้รายละเอียดกรณี

ส่วนนี้สรุปบริบทและเป้าหมายทางธุรกิจที่มีการจัดรูปแบบโซลูชันใบสั่งบริการ รวมถึงการตัดสินใจที่จะย้ายไปยัง Power Platform

บริบททางธุรกิจ

ความคิดริเริ่มนี้เริ่มต้นขึ้นเมื่อองค์กรกําหนดให้ย้ายกระบวนการจัดการใบสั่งบริการจากแพลตฟอร์ม Angular-Camunda ไปยัง Microsoft Power Platform

โซลูชันเดิมที่สร้างขึ้นจาก Angular, Camunda Workflow Engine และ PostgreSQL ค่าใช้จ่ายสิทธิ์การใช้งานสูงที่เกิดขึ้นจําเป็นต้องมีทีมทางเทคนิคเฉพาะสําหรับคําขอเปลี่ยนแปลงและเวลาในการแก้ไขปัญหามานานเพื่อการปรับปรุงประสิทธิภาพเล็กน้อย ความซับซ้อนของโซลูชันและค่าใช้จ่ายในการบํารุงรักษาทําให้องค์กรติดตามทางเลือกที่ทันสมัยประหยัดค่าใช้จ่ายและง่ายต่อการบํารุงรักษา

วัตถุประสงค์และผู้ขับขี่

โปรแกรมควบคุมหลักสําหรับโซลูชันใหม่:

• ใช้ประโยชน์จากสิทธิ์การใช้งาน Power Platform และโครงสร้างพื้นฐานที่มีอยู่ เพื่อลดค่าใช้จ่ายสิทธิ์การใช้งานเพิ่มเติม

• ลดการพึ่งพาการสนับสนุนด้านเทคนิคเฉพาะลดค่าใช้จ่ายในการดําเนินงาน

• จัดการการเปลี่ยนแปลงให้มีประสิทธิภาพ โดยใช้คุณลักษณะโค้ดต่ําและลดการพัฒนาแบบกําหนดเอง

• ส่งมอบโซลูชัน Power Platform ที่ลีนและดูแลรักษาได้ภายในหนึ่งเดือนเพื่อให้ตรงตามไทม์ไลน์ที่ก้าวร้าวของลูกค้า

• ตรวจสอบการโยกย้ายที่ราบรื่น ของกระบวนการที่มีอยู่และข้อมูลพื้นฐาน

• ปรับปรุงประสบการณ์ของผู้ใช้ ด้วยส่วนติดต่อที่ใช้งานง่ายและโต้ตอบได้

ส่วนประกอบ

ทีมออกแบบและนําแอปที่ขับเคลื่อนด้วยแบบจําลอง Power Apps มาใช้ที่ได้รับการสนับสนุนโดยคุณลักษณะหลักนอกกรอบ (OOTB) เพื่อให้การปรับแต่งน้อยที่สุดในขณะตอบสนองความต้องการการทํางานทั้งหมด

อินเทอร์เฟสผู้ใช้

แอปที่ขับเคลื่อนด้วยโมเดล ทําหน้าที่เป็นส่วนติดต่อผู้ใช้หลักสําหรับผู้ใช้

หน้าแบบกําหนดเอง ปรับปรุงประสบการณ์ผู้ใช้ให้ทันสมัยโดยมั่นใจได้ว่ามีลักษณะการทํางานของ UI แบบโต้ตอบและการเปลี่ยนแปลงน้อยที่สุดสําหรับผู้ใช้ปลายทาง เนื่องจากแอปพลิเคชันจะโยกย้ายจากแพลตฟอร์มที่มีอยู่

การเลือกกําหนดแถบคําสั่งจะจัดการกฎทางธุรกิจและกระบวนการอนุมัติผ่านลําดับขั้นที่แตกต่างกัน

โฟลว์กระบวนการทางธุรกิจ (BPF) ช่วยให้ผู้ใช้แสดงภาพลําดับขั้นที่มีอยู่ได้

การสร้าง PDF

ฟังก์ชันการส่งออก PDF ของระบบก่อนหน้านี้มีความซับซ้อนสูงและจําเป็นต้องมีการดําเนินการทางเทคนิคบ่อยครั้งสําหรับการอัปเดตเทมเพลตเพียงเล็กน้อย

โซลูชันใหม่ใช้:

• แม่แบบเอกสารเอนทิตี้ OOTB สําหรับการสร้าง Word/PDF

• การปรับเปลี่ยนเทมเพลตที่ควบคุมโดยผู้ดูแลระบบ ทําให้ไม่ขึ้นกับทีมเทคนิค

วิธีการนี้จะช่วยลดเวลาในการตอบสนองและขจัดความจําเป็นสําหรับการอัปเดตเทมเพลตที่ขับเคลื่อนโดยการพัฒนาได้อย่างมาก

เวิร์กโฟลว์และการอนุมัติ

ลําดับงานของกระบวนการทางธุรกิจ รวมการกําหนดเส้นทางคําขอ การอนุมัติ และการติดตามความคืบหน้าหลายขั้นตอน

Power Automate โฟลว์ ดําเนินการต่าง ๆ เมื่อเสร็จสิ้นแต่ละขั้นตอนการอนุมัติ เช่น ส่งการแจ้งเตือนไปยัง Outlook และทีม การกําหนดงาน และการสร้าง PDF อัตโนมัติในขั้นตอนสุดท้าย

การจัดการวงจรชีวิตและการยกเลิก

โฟลว์ Power Automate ทำงานทุกวันเพื่อตรวจสอบ (SLA) และใบสั่งบริการที่สิ้นสุดในวันนั้น

ตัวแจ้งเตือนงาน

โฟลว์ Power Automate ส่งการเตือนไปยังผู้ใช้ที่ได้รับมอบหมายงานเมื่อพ้นกำหนดวันที่ครบกำหนด

แหล่งข้อมูล

Dataverse เพื่อจัดการและจัดเก็บข้อมูลของแอปพลิเคชัน และคงประวัติบันทึกการตรวจสอบไว้

SharePoint เป็นที่เก็บเอกสารและสําหรับการกําหนดรุ่นเอกสาร

การรายงาน

Power Appsแอปพลิเคชันที่ขับเคลื่อนด้วยแบบจําลองแสดงแผนภูมิที่แสดงในรายงานและให้ข้อมูลเชิงลึกกับข้อมูลของแอปพลิเคชัน

ข้อควรพิจารณา

ข้อควรพิจารณาเหล่านี้ใช้เสาหลักของ Power Platform Well-Architected ซึ่งเป็นชุดหลักการชี้นําเพื่อช่วยปรับปรุงคุณภาพของปริมาณงาน เรียนรู้เพิ่มเติมเกี่ยวกับ Microsoft Power Platform Well-Architected

ความน่าเชื่อถือ

• กําหนดความคาดหวังที่ชัดเจนสําหรับ:

  • เวลาตอบสนอง
  • ไทม์ไลน์การอนุมัติ
  • ช่วงเวลาหน้าต่างงานประจำวัน (SLA หมดอายุ, งานยุติ)

• ใช้ความยืดหยุ่นตามงาน ตัวอย่างเช่น ถ้าขั้นตอน Power Automate ล้มเหลว:

  • เก็บงานดังกล่าวให้อยู่ใน Dataverse จนกว่าการดําเนินการที่เกี่ยวข้องจะเสร็จสิ้น

  • อนุญาตให้ผู้ใช้ลองส่งหรืออนุมัติอีกครั้งในขั้นตอนใดก็ได้

  • อัปเดตสถานะคําขอหลังจากดําเนินการขั้นตอนทั้งหมดในเวิร์กโฟลว์เท่านั้น

  • แสดงข้อผิดพลาดในโฟลว์กระบวนการทางธุรกิจถ้าการอัปเดตลําดับขั้นล้มเหลว

• จัดการความล้มเหลวของงานรายวันด้วยตรรกะใหม่และดึงข้อมูลตามตัวกรองแบบไดนามิก

• ใช้การดําเนินการที่สั้นและไร้สถานะของผู้ใช้เพื่อลดโอกาสของเวิร์กโฟลว์ที่ติดอยู่

• ใช้การบันทึกเพื่อเก็บคําขอข้อมูลที่เชื่อถือได้และสนับสนุนการตรวจสอบย้อนกลับ

Security

• ควบคุมการเข้าถึงแอปที่ขับเคลื่อนด้วยแบบจําลองโดยใช้กลุ่มความปลอดภัย Microsoft Entra ID แมปกับทีมเจ้าของ Dataverse

• กําหนดบทบาทความปลอดภัยสําหรับผู้รับผิดชอบเชิงพาณิชย์ ที่รับผิดชอบหลัก ผู้ร้องขอ และผู้ดูแลระบบเพื่อรักษาความปลอดภัยการเข้าถึงข้อมูลอย่างชัดเจน

• เชิญผู้ใช้ที่เป็นผู้เยี่ยมชมให้ Microsoft Entra ID ตามนโยบายองค์กร และเพิ่มลงในกลุ่มความปลอดภัยหลังจากอนุมัติเท่านั้น ใช้กลุ่มความปลอดภัยเดียวกันสําหรับผู้ใช้ภายนอกที่ได้รับอนุมัติ

• ใช้การรักษาความปลอดภัยระดับสนามและระดับแถวใน Dataverse

• ให้สิทธิ์ SharePoint ผ่านการรวมภายในกับแอปพลิเคชัน Dataverse และแอปพลิเคชันที่ขับเคลื่อนด้วยแบบจําลอง

• ปรับใช้แอปพลิเคชันใน สภาพแวดล้อมที่มีการจัดการ และกําหนดนโยบายข้อมูลเฉพาะสําหรับแอปพลิเคชันนั้น

• ใช้การบันทึกการตรวจสอบข้อมูลเพื่อตรวจหาความผิดปกติของข้อมูล

• ทําให้ข้อมูลเป็นแบบอ่านอย่างเดียวหลังจากคําขอถึงขั้นตอนที่เฉพาะเจาะจง

• ใช้นโยบายการเก็บถาวรเพื่อให้แน่ใจว่าผู้ดูแลระบบสามารถควบคุมข้อมูลที่เก็บถาวรได้ทั้งหมด และผู้ใช้สามารถเข้าถึงเฉพาะเอกสาร PDF ที่สร้างขึ้นสําหรับคําขอแต่ละครั้งเท่านั้น

ความเป็นเลิศในการดำเนินงาน

• กําหนดกลยุทธ์ของสภาพแวดล้อมเพื่อให้แน่ใจถึงความเป็นเลิศในการดําเนินงาน ตั้งค่าสภาพแวดล้อมการพัฒนา การทดสอบ และการผลิต และกําหนดค่าเป็น สภาพแวดล้อมที่มีการจัดการ ตามความเหมาะสม

• ใช้กลยุทธ์โซลูชัน:

  • ใช้โซลูชันที่ไม่มีการจัดการในสภาพแวดล้อมการพัฒนาและโซลูชันที่มีการจัดการในสภาพแวดล้อมอื่น ๆ

  • ออกแบบการแบ่งเซกเมนต์โซลูชันให้กับส่วนคอมโพเนนต์ UI กระบวนการ และคอมโพเนนต์หลัก

• ใช้การตรวจทานโค้ดก่อนย้ายจากสภาพแวดล้อมการพัฒนา

• สร้างแอปแบบจําลองข้อมูลบนโครงสร้างที่มีโค้ดต่ําเพื่อปรับปรุงและแก้ไขข้อบกพร่องได้เร็วขึ้น

ประสิทธิภาพการทำงาน

• ระบุรูปแบบปริมาณธุรกรรมจากแอปพลิเคชันเก่าและเห็นด้วยกับธุรกิจเกี่ยวกับข้อมูลปริมาณข้อมูลที่รวบรวม

• มอบหมายกิจกรรมที่ทํางานนาน เช่น การหมดอายุของ SLA และการสิ้นสุดการทํางาน ไปยังโฟลว์ที่กําหนดไว้ที่ไม่ขึ้นอยู่กับการโต้ตอบของผู้ใช้

• ใช้ API แบบแบทช์สำหรับการดำเนินการ CRUD จำนวนมากเพื่อหลีกเลี่ยงขีดจำกัดการจัดการปริมาณ

การปรับปรุงประสบการณ์ใช้งาน

• สร้างเพจแบบกําหนดเองเพื่อปรับปรุงเพจเริ่มต้น

• ส่งอีเมลที่จัดรูปแบบอย่างดีเพื่อให้ผู้ใช้สามารถระบุได้อย่างง่ายดาย

• รวมลิงก์ลึกในอีเมลเพื่อให้ผู้ใช้สามารถไปยังคําขอได้โดยตรง

• ส่งการเตือนความจําทันเวลาเพื่อช่วยให้ผู้ใช้ทํางานให้เสร็จสมบูรณ์ได้ทันเวลา

• เพิ่มลิงก์ด่วนไปยัง งานของฉัน และส่วนผู้ดูแลระบบ

• เพิ่มปุ่มแบบกําหนดเองที่ผู้ใช้สามารถเลือกเพื่อระบุการดําเนินการที่จะใช้

• แจ้งให้ผู้ใช้ทราบถึงความสําเร็จหรือความล้มเหลวหลังจากการเลือกปุ่มแต่ละครั้ง

• ซ่อนข้อมูลที่ไม่จําเป็นเมื่อคําขอถึงขั้นตอนที่เฉพาะเจาะจง

• เก็บข้อมูลถาวรเพื่อให้ผู้ใช้เห็นเฉพาะรายการที่ใช้งานอยู่

แหล่งข้อมูลที่เกี่ยวข้อง

• แอปที่ขับเคลื่อนด้วยโมเดลใน Power Apps คืออะไร?
• เพิ่มหน้าแบบกำหนดเองลงในแอปแบบจำลองของคุณ
• ภาพรวมโฟลว์กระบวนการธุรกิจ
• เอกสารประกอบ Power Automate
• เอกสาร Dataverse
• จัดการทีมกลุ่ม
• ใช้เทมเพลต Excel และเทมเพลต Word
• ภาพรวมสภาพแวดล้อมที่มีการจัดการ

ผู้สนับสนุน

Microsoft ดูแลบทความนี้ ผู้เขียนต่อไปนี้ได้เขียนบทความนี้

ผู้เขียนหลัก:

• Rakhi Jain, สถาปนิกด้านเทคนิค