---
schema_version: "1"
id: 1fddf3c3e0f47581066582875fbbf8f125fc7cb7a01cd2b4e8c6677be0a3224c
title: Implicit Configurations
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-sdk/latest/implicit-configurations.md
canonical_url: https://docs.mulesoft.com/mule-sdk/latest/implicit-configurations
source_site: docs.mulesoft.com
content_type: documentation
content_hash: e8d94dc955fa96c6a67444474530c3a315c063989a1d74c8bd1113659cc48d17
description: MuleSoft Documentation Site
release: "1.13"
latest: true
---
---
product: Mule SDK
version: 1.13
is-latest-version: true
---

# Implicit Configurations

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Some configurations can be classified as implicit. A configuration can be used implicitly when none
of its parameters are required. For example, suppose a `myConfig` configuration object which has a
required parameter `param1`:

```java
<example:my-config name="myConfig" param1="required value" />

<flow>
	<example:operation config-ref="myConfig" />
</flow>
```

Now suppose that the bar parameter were to turn optional instead:

```java
<example:my-config name="myConfig" />

<flow>
	<example:operation config-ref="myFoo" />
</flow>
```

In this case, the entire my-config element (and subsequent config-ref) are redundant because they
have no real effect. In these cases, implicit configurations can be used:

```java
<flow>
	<example:operation />
</flow>
```

Because `my-config` does not have required parameters, the SDK can create an implicit instance in
which all parameters are automatically assigned to their default values. The implicit configuration
is either static or dynamic depending on its parameter’s default values. If any of those default
values is an expression, then the implicit configuration is dynamic.

> [!NOTE] Using an expression as a default value violates the best practice of the
> [position independence](https://docs.mulesoft.com/mule-sdk/latest/define-operations#position-independence).

## Mixing Implicit and Explicit Configurations

You can use implicit and explicit configurations in tandem:

```java
<flow>
	<example:operation />
	<example:operation config-ref="myConfig" />
</flow>
```

> [!TIP] Only one implicit `config` is created per configuration type. If two operations try to use
> implicit configurations of the same type, each uses the exact same instance:

```java
<flow>
	<example:operation />
	<example:operation />
	<!-- Both operations use the same config instance -->
</flow>
```

## Forcing Explicit Configurations

Available since version 1.3.

There are cases in which you might want to force configurations to always be explicit, even if they
contain no required parameters. Usually, such requirements revolve around clarity and usability
concerns.

Use the `@NoImplicit` annotation to instruct the SDK to never build implicit instances of a given
configuration type:

```java
@Extension(name="example")
@NoImplicit
@Operations(ExampleOperations.class)
public class ExampleModule {

	@Parameter
	@Optional
	public String bar;



}
```

You can also use this annotation if your configuration has been externalized into a separate class:

```java
@Extension(name="example")
@Configurations(MyConfiguration.class)
public class ExampleModule {

}

@Configuration(name="myConfig")
@NoImplicit
@Operations(ExampleOperations.class)
public class MyConfiguration {

	@Parameter
	@Optional
	public String bar;


}
```