Mga workflow ng pag-apruba

Karaniwang nangyayari ang pag-apruba sa labas ng tool na nagpu-publish. May napupuntang screenshot sa isang kliyente, sumasagot ang kliyente ng oo, tapos nagbabago ang copy. Ang pag-apruba ngayon ay tumutukoy sa isang draft na wala nang meron, at wala talagang alam ang tool, kaya ini-publish nito kung ano man ang huling ibinigay dito.

• Naka-attach ang isang pag-apruba sa eksaktong nilalamang na-review. Ang pag-edit sa isang aprubadong draft ay nagpapawalang-bisa sa pag-aprubang iyon at nagsasabi kung aling field ang nagbago, sa halip na tahimik lang dalhin pasulong ang lumang desisyon.
• Puwedeng aprubahan, hilingin ang mga pagbabago, o tanggihan ng isang reviewer, at kailangan ng komento para sa anumang bagay maliban sa pag-apruba, kaya hindi na kailangang manghula ng may-akda kung ano ang aayusin.
• Nasa shared application layer ang panuntunan, kaya sinusunod ito ng web app, REST API, MCP server, CLI, at webhook. Walang surface na may shortcut sa review.

Nagawa na ang mga approval state, ang review surface, ang mga panuntunan sa muling pag-apruba, at ang mga audit event sa likod ng mga ito. Ang hindi pa nagagawa ay ang huling hakbang, dahil wala pang koneksyon na nakumpleto ang definition of done nito, kaya wala pang mapupuntahan ang isang aprubadong post.

Dala ng capability matrix ang bawat platform at bawat capability sa isang table. Inilalarawan ng mga page ng use case ang mga workflow na pinagbubuuan ng produktong ito.

Mga use case

Pag-iiskedyul, kada platform

Mga kakayahan sa platform