diff --git a/charts/vela-core/templates/defwithtemplate/multi-env.yaml b/charts/vela-core/templates/defwithtemplate/deploy2env.yaml
similarity index 87%
rename from charts/vela-core/templates/defwithtemplate/multi-env.yaml
rename to charts/vela-core/templates/defwithtemplate/deploy2env.yaml
index e7198173c..84f9fd929 100644
--- a/charts/vela-core/templates/defwithtemplate/multi-env.yaml
+++ b/charts/vela-core/templates/defwithtemplate/deploy2env.yaml
@@ -1,11 +1,11 @@
 # Code generated by KubeVela templates. DO NOT EDIT. Please edit the original cue file.
-# Definition source cue file: vela-templates/definitions/internal/multi-env.cue
+# Definition source cue file: vela-templates/definitions/internal/deploy2env.cue
 apiVersion: core.oam.dev/v1beta1
 kind: WorkflowStepDefinition
 metadata:
   annotations:
-    definition.oam.dev/description: Apply env binding component
-  name: multi-env
+    definition.oam.dev/description: Deploy env binding component to target env
+  name: deploy2env
   namespace: {{.Values.systemDefinitionNamespace}}
 spec:
   schematic:
diff --git a/design/vela-core/environment.md b/design/vela-core/environment.md
index 9f4d85ace..da07b18a6 100644
--- a/design/vela-core/environment.md
+++ b/design/vela-core/environment.md
@@ -75,7 +75,7 @@ For example, we can deploy an application to dev env first, then verify the app
 We can use the following Definition to achieve that:
 
 - env-binding Policy: This defines the config patch and placement strategy per env.
-- multi-env WorkflowStep: This picks which policy and env to deploy the app to.
+- deploy2env WorkflowStep: This picks which policy and env to deploy the app to.
 - suspend WorkflowStep: This will pause the workflow for some manual validation.
 
 Below is an example:
@@ -122,7 +122,7 @@ spec:
   workflow:
     steps:
       - name: deploy-test-env
-        type: multi-env
+        type: deploy2env
         properties:
           policy: my-binding-policy
           env: test
@@ -131,7 +131,7 @@ spec:
         type: suspend
 
       - name: deploy-prod-env
-        type: multi-env
+        type: deploy2env
         properties:
           policy: my-binding-policy
           env: prod
@@ -143,12 +143,12 @@ Here're more details for above example:
   In each env, it defines the config patch and placement strategy specific to this env.
 - When the application runs, it triggers the following workflow:
   - First it picks the policy, and picks the `test` env which is also defined inside the policy.
-  - Then the `multi-env` step will loads the policy data, picks the `test` env specific config section.
+  - Then the `deploy2env` step will load the policy data, picks the `test` env specific config section.
     This step will render the final Application with patch data,
     and picks the cluster to deploy to based on given placement strategy,
     and finally deploys the Application to the cluster.
   - Then it runs `suspend` step, which acts as an approval gate until user validation 
-  - Finally, it runs `multi-env` step again. Only this time it picks the `prod` env.
+  - Finally, it runs `deploy2env` step again. Only this time it picks the `prod` env.
     This step will render the final Application with patch data,
     and picks the cluster to deploy to based on given placement strategy,
     and finally deploys the Application to the cluster.
diff --git a/vela-templates/definitions/internal/multi-env.cue b/vela-templates/definitions/internal/deploy2env.cue
similarity index 85%
rename from vela-templates/definitions/internal/multi-env.cue
rename to vela-templates/definitions/internal/deploy2env.cue
index a519c84ee..23fc1268e 100644
--- a/vela-templates/definitions/internal/multi-env.cue
+++ b/vela-templates/definitions/internal/deploy2env.cue
@@ -2,11 +2,11 @@ import (
 	"vela/op"
 )
 
-"multi-env": {
+"deploy2env": {
 	type: "workflow-step"
 	annotations: {}
 	labels: {}
-	description: "Apply env binding component"
+	description: "Deploy env binding component to target env"
 }
 template: {
 	app: op.#ApplyEnvBindApp & {