Power Automate Action Settings Explained
- Sivakumar K
- Oct 4
- 4 min read
When you build flows in Power Automate, every action you add comes with a Settings panel (the gear icon). These settings determine how your action executes, how failures are handled, and how sensitive data is secured.
In this article, we’ll walk through each setting with practical examples so you can use them effectively in your flows.
General → Action Timeout
Networking → Retry Policy
Run After
Security → Secure Inputs and Outputs
Tracking → Tracked Properties
Concurrency Control vs Retry Policy
General → Action Timeout
The Action Timeout defines how long Power Automate should wait for this action before failing.
Example: If you’re calling an external API that usually responds within a few seconds, set a timeout like PT2M. If the API doesn’t respond in 2 minutes, the action fails, and your retry or error handling logic can take over.
Format: ISO 8601 Duration (e.g., PT5M = 5 minutes, P1D = 1 day).
P → period (starts the duration expression)
T → separates the date part from the time part
D → days
H → hours
M → minutes
S → seconds
Networking → Retry Policy
The Retry Policy controls what happens when an action fails because of temporary issues (like API timeouts, throttling, or service errors), Power Automate can automatically retry the action instead of failing immediately. You can configure this behaviour using the Retry Policy under action settings.
Example: When sending an HTTP request to SharePoint Online, set Fixed Interval → 3 retries, 30 seconds apart. This ensures that if the service is busy, your request will try again without failing the entire flow
Options:
Default: Retries up to 4 times with exponential delay.
None: No retries, fails immediately.
Fixed Interval: Retry after fixed intervals (e.g., 3 retries every 30s).
Exponential Interval: Retry with increasing gaps between attempts.
Default:
Retries up to 4 times.
Uses an exponential backoff delay:
1st retry → 5 seconds
2nd retry → 10 seconds
3rd retry → 20 seconds
4th retry → 40 seconds
None:
No retries at all. If the action fails once, the flow stops (or follows your Run After error path).
Fixed Interval
Retries the action a set number of times with a fixed wait interval between retries.
Exponential Interval
Similar to Default, but you can configure the retry count and maximum wait interval. The delay doubles each time until it reaches the maximum.
Example:
Max Retries = 4
Minimum interval = 10s, Maximum interval = 120s
Retry delays: 10s → 20s → 40s → 80s
Run After
The Run After setting lets you control whether the action should run after a previous step succeeds, fails, gets skipped, or times out.
Security → Secure Inputs and Outputs
If your action handles sensitive data (like passwords, tokens, or personal details), you can hide it in the run history.
Secure Inputs → Masks incoming data.
Secure Outputs → Masks outgoing results.
Tracking → Tracked Properties
The Tracked Properties setting lets you attach custom metadata (key–value pairs) to an action. These values are then included in the flow run history and outputs, making it easier to:
Debug flows
Build audit logs
Feed monitoring tools (like Power BI, Application Insights, or Azure Monitor)
Think of it as adding your own “labels” to steps in your flow.
Concurrency Control
By default, Power Automate can process multiple flow runs in parallel. Concurrency control allows you to limit or control how many runs happen at the same time.
Limit toggle (On/Off)
Off: Unlimited runs in parallel.
On: You define the maximum degree of parallelism.
Degree of parallelism (slider/number box)
Defines how many flow runs can run simultaneously.
Example: If set to 20 (like in your screenshot), up to 20 runs will execute at the same time.
Maximum waiting runs
Defines how many flow instances can queue up if the concurrency limit is reached.
Example: If set to 10, then once the limit (20 parallel runs) is reached, only 10 additional runs will wait in the queue. The 11th waiting run will fail automatically.
Trigger Conditions
Trigger conditions allow you to define rules that decide whether a flow should even start.
Written as expressions (Power Fx / Workflow Definition Language).
Flow runs only if the condition is true.
Helps reduce unnecessary flow runs, saving performance and licensing costs.
Example Use Case:Trigger: When a new item is created in SharePoint. Condition: Run the flow only if Priority = High
Concurrency Control vs Retry Policy
Concurrency Control → Works at the flow level (or loop level like Apply to Each). It controls how many flow runs or loop iterations can execute at the same time.
Example: Degree of parallelism = 10 → 10 runs can execute in parallel.
Retry Policy → Works at the action level inside a flow run. It defines how an individual action behaves if it fails (retry count, delay pattern, exponential/fixed).
Example: Retry an HTTP request 3 times every 30 seconds.
Key Clarification
Concurrency ≠ Retry → They operate at different layers.
Retry Policy is not impacted by Concurrency Control.
Each action run applies its own retry policy, regardless of how many other runs are happening in parallel.
Concurrency only controls parallelism (how many jobs/iterations run at once).
If concurrency is high and many actions fail simultaneously, all of them will retry independently (which can increase load).