User Roles

This setting modifies editorial behavior in the admin and does not impact the GraphQL Schema or GraphQL resolvers.

This is a presentational field in the WordPress admin and has no impact on the GraphQL Schema or GraphQL resolvers.

This is a presentational field in the WordPress admin and has no impact on the GraphQL Schema or GraphQL resolvers.

This setting modifies editorial behavior in the admin and does not impact the GraphQL Schema or GraphQL resolvers.

This field is presentational and has no impact on the WPGraphQL Schema or WPGraphQL resolvers.

This setting modifies editorial behavior in the admin and does not impact the GraphQL Schema or GraphQL resolvers.

This setting modifies editorial behavior in the admin and does not impact the GraphQL Schema or GraphQL resolvers.

Checking this field will set the field as a NonNull field in the WPGraphQL Schema. Changing a field from nullable to NonNull is a non-breaking change to the Schema. BUT, changing a field from NonNull to nullable IS a breaking change to the schema, so be careful with this option. Also, because of the dynamic nature of ACF, it’s difficult to guarantee a value will exist for the field. For example, you might already have 100 posts published with no value for the field, so setting the field to “Non-Null” in GraphQL will lead to errors for those posts that have no value to return. It’s recommended to only use this setting if the field has been marked as “required” the entire time the field has been available.

Checking this will expose the field to the GraphQL Schema. 

NOTE: If a field is added to the GraphQL Schema, then later removed from the Schema, this is considered a breaking change as client applications that were querying for the field would be breaking once it’s been removed from the Schema.

The description of the field that is returned when using Schema Introspection queries, used by tools such as the GraphiQL IDE.

The name of the field in the GraphQL Schema. The name must be unique to the Field Group (i.e. there cannot be 2 fields in one ACF Field Group with the same “GraphQL Field Name”, including when using Clone Fields). 

This is the name that is used to store field data in meta tables. The name will not affect the GraphQL Schema, but if the name is changed after data is already saved, it might impact resolution of the previously stored data. Changing the field name could negatively impact the GraphQL experience.

This value should be returned as the GraphQL field value if no value has been set for the field.

The “required” setting on an ACF Field does not directly impact the WPGraphQL Schema. While it might seem like setting an ACF Field to “required” should enforce the field to be a “Non Null” field in the GraphQL Schema, we believe this would be a mistake. Setting a field in the GraphQL Schema as “NonNull” will return errors if no data is present to be returned. Since the “required” setting can be toggled “on” on an ACF Field long after content already exists with no data for the field, this would cause errors to be returned for older content, and we believe this to be unexpected behavior. Instead of tying “GraphQL Non Null” to the ACF “Required” setting, we’ve provided a “GraphQL: NonNull” setting where you can explicitly opt-in to a field being “Non Null” in the Schema.

This field is used to tell people in the WordPress admin how to use the field. If a “GraphQL Description” is not provided for a field, the “instructions” will be used as a fallback in GraphQL Introspection queries, used in tools such as the GraphiQL IDE.

Conditional Logic should not impact the GraphQL Schema. Fields that are conditionally available in the admin should always be available in the Schema. The data that is resolved for a field might be impacted by conditional logic.

This is a presentational field in the WordPress admin and has no impact on the GraphQL Schema or GraphQL resolvers.