`). ## Flow Configuration Flows are configurable. For example, you can set them to start or remained stopped when the Mule app starts, place limits on the allowed concurrency, or set up business events. You can also set up error handling for a component (see [Error Handling](#error_handling)).

Field	Description
Name (`name`)	Name for the flow. Flows automatically receive an editable name that matches (or partially matches) the project name.
Initial State (`initialState`)	Values: Started, Stopped. These are Mule runtime settings for the flow. The default, Started (`initialState="started"`, also called Empty in Studio), indicates that the flow is active when you start the app. So it can be triggered by an internal or external Mule event source within the flow (such as an HTTP listener or Scheduler), by a Flow Reference from another flow or subflow, or through a call to the lookup function. If you set the initial state to Stopped (`initialState="stopped"`), activate the flow after deployment. For hybrid standalone and Anypoint Platform PCE deployments, use Runtime Manager to activate the flow. For CloudHub and Anypoint Runtime Fabric deployments, flow management through Runtime Manager isn’t supported. To activate the flow, redeploy the application or update the flow configuration to Started. When a flow is deployed with the initial state set to Stopped, the console output looks similar to this: `Flow flow_component_ex has not been started (initial state = 'stopped')`. For CloudHub deployments, avoid setting `initialState="stopped"` on flows that contain a Scheduler. The scheduler gets stuck in a permanent "Running" state, and you can’t manage it through Runtime Manager.
Max Concurrency (`maxConcurrency`)	Optional. Sets the maximum number of concurrent messages that a flow can process. If not set, the container thread pool determines the maximum number of threads the flow can use to optimize the performance when processing messages. While the flow is processing the maximum number of concurrent messages, it cannot receive additional requests. Set `maxConcurrency` to `1` to cause the flow to process requests one at a time. See Back-pressure for details about Mule’s behavior after the the maximum concurrency value is reached.
Business Events	Optional: Defaults to `false`. For Mule apps that you deploy to CloudHub, you can enable business events (XML example: `tracking:enable-default-event="true"`) and add a Transaction ID (XML example: `<tracking:transaction id=12345`/>). See Business Events.
Metadata	As with many other components, you can set metadata for this component. For more on this topic, see the Studio document Metadata Editor.

## Subflow Configuration Subflow scopes provide a way to edit the name of the subflow and to add metadata. Unlike flows, subflows lack a built-in mechanism for setting up error handling, though you can use error handling provided by the [Try Scope](https://docs.mulesoft.com/mule-runtime/4.4/try-scope-concept) within a subflow if you need to perform error handling.

Field	Description
Name (`name`)	Name for the subflow. Subflows automatically receive an editable name that matches (or partially matches) the project name.
Metadata	As with many other components, you can set up metadata for this component. For more on this topic, see the Studio document Metadata Editor.

## XML for Flows and Subflows This example shows the XML for a simple flow (``) that uses a Scheduler as a source to trigger execution of the flow every 10 seconds, and it connects to a subflow (``) through a Flow Ref (``) component. That subflow then connects to another subflow, also using a Flow Ref component. Note that when you configure components through the Studio UI, Studio automatically adds the XML to the Configuration XML for your Mule app. Example: XML for a Flow and Subflows ```xml

9.99 53 398.99 ', 'application/xml') output application/xml --- myXml ]]>

{ (key) : { dollars: value, localCurrency: value * conversionRate, index_plus_1: index + 1, timer : currentMilliseconds() } }]]>

``` The example produces the following output: Output ```json { "priceList": { "basic": { "dollars": "9.99", "localCurrency": 129.87, "index_plus_1": 1, "timer": 1533024312658 }, "premium": { "dollars": "53", "localCurrency": 689, "index_plus_1": 2, "timer": 1533024312659 }, "vip": { "dollars": "398.99", "localCurrency": 5186.87, "index_plus_1": 3, "timer": 1533024312659 } } } ``` ## Error Handling You can add [error handlers](https://docs.mulesoft.com/mule-runtime/4.4/error-handling) to the Flow components (but not to subflows). In Studio, you can simply expand the Error Handling area at the bottom of the Flow component and drag the error components into the flow. Note that this process automatically places the component into the Error Handler component, so there is no need to add the Error Handler component first. Near the end of this XML example, the flow shows an On Error Continue configuration (``): Example: XML for Flow with On Error Continue Configuration ```xml

', 'application/xml') output application/xml --- myXml ]]>

``` The preceding example produces an error. Notice the following: 1. The variable `var myXml` in `` configures an empty `` tag as the payload. 2. The Logger beside the `` component returns `null` because it is set to log the value of the empty tag. 3. The `` component returns an error because the DataWeave condition `isEmpty(payload.prices)` returns `true`. 4. The Logger (``) within `` configures an error message to print to the console when an error occurs. The resulting error message looks something like this: ```text ERROR 2018-07-30 23:58:45,293 [[MuleRuntime].cpuLight.06: [flow_subflow].flow_subflowFlow.CPU_LITE @1b1529b2] [event: 0-2aba3280-948f-11e8-82d0-f45c898f2549] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: "An Error Occurred" ``` For details about these components, see [On-Error](https://docs.mulesoft.com/mule-runtime/4.4/on-error-scope-concept) error handlers. ## See Also - [Back-Pressure and MaxConcurrency](https://docs.mulesoft.com/mule-runtime/4.4/tuning-backpressure-maxconcurrency)