Resource Forms

Resource forms are how Clophi presents Azure resource configuration. Each form is the intelligent equivalent of a resource's ARM template, Bicep, or Terraform AzAPI structure. Instead of writing that structure by hand, you configure the resource through a guided form that exposes every property, validates your input, and handles the connections between resources for you.

Authoring configurations for production-grade resources is a demanding task, and the form's deterministic tools exist to guide you, accelerate the work, and reduce the room for error. Resource forms are built specifically to support the highly technical workflows required by senior Azure architects.

When you load a resource, the screen is split into two areas: the form on the left, and a tab on the right.

The Resource Form

The form lists every property the resource supports. Required fields are marked, and inputs are type-based to match the underlying schema:

• Boolean properties render as checkboxes.
• String properties with a fixed set of allowed values render as dropdowns.
• Objects and simple arrays render their inputs with type validations.
• Integer properties accept integers only.

Beyond type validation, some fields apply specific regex validators to catch malformed values before deployment.

Object arrays

Properties that hold an array of objects are marked with a plus icon next to the title. Use it to add a new object to the array, and the trash icon to remove.

Resource references

Some fields need a reference to another resource. You have two options:

• Reference an existing resource in your tenant. Clophi fetches your resources and filters them to the ones valid for that specific reference field.



• Reference a resource that is part of the current infrastructure. The matching resource type is listed in the right tab for you to select.

Secret references

Sensitive inputs, such as admin passwords, are typed as secrets in Clophi. For such sensitive values, "Secret Reference" option is used. Clophi stores secrets in the Clophi Customer Key Vault, which is deployed in your own tenant. You can select an existing secret from the dropdown, or create a new one on the fly with the plus button and reference it immediately. Secrets are visible only to the user who created them. You can also delete secrets by clicking on the trash icon. (Note: You can also opt to provide such sensitive values as plain text by using "Secret as plain text" button, yet this is not recommended!)

Selectors

A field whose name ends in "Selector" generates a complete configuration for a target object so you do not have to configure it manually. For example, a Data Disk Selector builds the data disk configuration for a VM. Choosing "1 TB empty" populates the default values for caching, create option, delete option, disk size, name, and managed disk storage account type. The chosen default values can be further customized by your inputs when that's needed as well.

Bounded fields

Configuring one field can make another field required. Clophi enforces these dependent fields, so you complete the object correctly. For example, naming an inbound NAT rule on a load balancer reveals the other fields that NAT rule requires.

Disablers

Entering a value can make other properties irrelevant. Clophi removes those properties from view to prevent invalid combinations. For example, selecting a public IP address ID for a frontend IP configuration removes Private IP related fields such as private IP allocation method, private IP address version, private IP address, and subnet ID, since a single frontend IP configuration can either have a public IP or a private IP.

Inter-related objects

Some Azure resources require you to reference objects within the same resource the way you would reference an external resource. In a Load Balancer, for instance, an Outbound Rule must reference a backend address pool by its full Azure resource ID. When you create a Backend Pool named "app-backend-pool", that name appears in the Backend Address Pool dropdown of the Outbound Rule. You select the name, and Clophi resolves the full resource ID behind the scenes.

Dynamic ARM Schemas

Some resources do not have a fixed schema. Depending on the choices you make, the shape of a resource schema can change entirely. In an Event Subscription resource (for Event Grids), for example, the Destination object's Endpoint Type can take several values, and each value produces a completely different schema. A single static resource version cannot represent this. Clophi handles it with elective fields, which are denoted with "(Elective)" at the end of their names. You select the option you want, and Clophi re-structures the schema accordingly. This works for nested cases as well, so you can configure the schema without tracking the structural rules yourself.

Add child resources over existing Azure resources

To deploy a child resource onto an existing Azure resource, load the child resource form via the Child Resources section. The Origin Resource Reference field will automatically populate with compatible, existing Azure resources of a matching type. Simply select the target Azure resource from this list to deploy the child resource onto it.

Live Code on the fly

When working with complex and large resources like virtual machines, load balancers, and application gateways, it is quite useful to view the entire configuration structure on a single screen. You can use the Code tab to review the live configuration as you build, and use the property tree above the code to jump between properties.

The Right Tab

The right tab has five sections:

1. Resource information

Change the API version, jump to fundamental properties (clicking a property navigates the form to that field, which is useful in large forms), and access the drafts list. Drafts are ready-made resource configurations that accelerate creation. You can also save your own custom drafts here.

2. Resource docs

Detailed information about the resource. The additional information section links out to the official Azure documentation, and the relevant architecture section lists the built-in architectures that use this resource.

3. Property documentation

Documentation for individual properties. Clicking the exclamation mark icon, or any input field, loads the documentation for that property here. It draws on property's official documentation extended with expert guidance with reference to real-world use cases and links to relevant documentation.

4. Add child resource

If the resource you work on has available child resources, you can add child resources onto it from here. You must first give the current resource a name, to see the list of available child resources. Selecting a child resource type will open its own resource form.

5. Code

The live ARM template equivalent of your current configuration, useful for understanding how your form input maps to exported code, can be viewed here. Above the template, the resource's main properties are listed so you can navigate them by clicking.