diff --git a/docs/user_guide/flyte_fundamentals/registering_workflows.md b/docs/user_guide/flyte_fundamentals/registering_workflows.md
index 8a5ec83c14..15f6fb6874 100644
--- a/docs/user_guide/flyte_fundamentals/registering_workflows.md
+++ b/docs/user_guide/flyte_fundamentals/registering_workflows.md
@@ -365,6 +365,17 @@ two GitHub actions that facilitates this:
   of Flyte packages, for example, the `.tgz` archives that are created by
   `pyflyte package`.
 
+### Some CI/CD best practices
+
+In case Flyte workflows are registered on each commit in your build pipelines, you can consider the following recommendations and approach:
+
+- **Versioning Strategy** : Determining the version of the build for different types of commits makes them consistent and identifiable. For commits on feature branches, use `<branch-name>-<short-commit-hash>` and for the ones on main branches, use `main-<short-commit-hash>`. Use version numbers for the released (tagged) versions.
+
+- **Workflow Serialization and Registration** : Workflows should be serialized and registered based on the versioning of the build and the container image. Depending on whether the build is for a feature branch or main, the registration domain should be adjusted accordingly. For more context, please visit the [Registering workflows](https://docs.flyte.org/en/latest/user_guide/flyte_fundamentals/registering_workflows.html) page.
+
+- **Container Image Specification** : When managing multiple images across tasks within a Flyte workflow, use the `--image` flag during registration to specify which image to use. This avoids hardcoding the image within the task definition, promoting reusability and flexibility in workflows.
+
+
 ## What's next?
 
 In this guide, you learned about the Flyte demo cluster, Flyte configuration, and