--- title: "An HCL View for Rules, Operations and Resources in the Clarive Interface | Clarive" description: "Clarive 7.22 brings HCL into the browser, one object at a time. A rule can be read and edited as text in the Rule Designer, a single step in its dialog, and resources, roles and user groups on their own screens. Saves go through the same engine as cla import." url: "https://clarive.com/blog/hcl-in-the-clarive-interface" published: "2026-10-10" author: "Ricardo Martinez" --- # An HCL View for Rules, Operations and Resources in the Clarive Interface The Rule Designer, the operation dialog and the resource editor in Clarive 7.22 can show the object being edited as text and save it from there. The command line is where HCL handles a whole configuration. Most people who build pipelines in Clarive spend their day in the browser. For them, 7.22 puts the same text where they already work. It covers one object at a time: the rule open in the Rule Designer, the step open in its dialog, the resource or role on screen. Everything in this post goes through the encoder, decoder and apply that `cla export` and `cla import` use, described in the [first post of this series](https://clarive.com/blog/clarive-configuration-as-hcl). We didn't write a second save path for the browser. Two of them would drift apart within a release, and a snippet copied from the interface would stop meaning the same thing on the command line. ## A rule as text The Rule Designer's toolbar has a new HCL button, an icon with braces around an H. It is also in the menu, under More and then HCL. The button is a toggle. Its tooltip reads HCL View on the way in and Back to the tree on the way out, and it stays in the primary color while the text is showing. The text replaces the tree the way the flowchart view does, and leaving with unsaved changes asks first. What appears is the rule written exactly as the [previous post on rules](https://clarive.com/blog/writing-clarive-rules-in-hcl) described it, one nested block per step. The expand and collapse buttons fold the text instead of the hidden tree, one level per press, and their tooltips change to Expand One Level and Collapse One Level to say so. Folding changes only what is drawn and is never an unsaved change. A Show disabled switch sits next to All attributes. Turned off, it folds every block marked `disabled = true` down to a single marker, and a run of disabled blocks shares one. They are folded and not removed. The text still holds them, so a save stores them unchanged, where removing them from the text would have deleted them. All attributes rewrites the text with every parameter of every step written out, including the ones left at their defaults. The rule list has a way in as well. Each row's action menu has an HCL entry that opens the same editor in a window titled with the rule's name. The editor checks the text while it's being written. Half a second after typing stops, it sends the text to the server, which parses it and then decodes it, because text that parses isn't necessarily text that means anything. Problems are marked in the gutter, and a status line at the right of the editor's toolbar shows one of them, with its line and column, or reads No problems. Only the first error is shown there, since later ones are usually the same mistake repeated. Clicking the status line opens the full list, each problem with a link to its line. A dot appears while there are unsaved changes. ## Saving from the text A save goes into the Rule Designer's own save. Versioning, the check for someone else having saved first and the rule events all behave as they do for a save from the tree. The text is formatted before it is sent, so what is stored is what the command line would have written, and a later `cla export` shows no difference that came only from spacing. Nothing broken is stored. Text with errors is rejected and the stored rule stays as it was. A rule that reads back but doesn't compile is refused by the rule compiler, and its errors appear on the steps they came from, in the compiler's own words, instead of at line numbers in generated code that nobody can see. After a save the editor reloads, because a save can legitimately change the text as defaults settle, and editing a stale copy invites a second save built on a wrong picture. One thing to know before switching a busy rule to text. Each step of a rule saved from the HCL view is given a new internal step id, so its job history and profile start again. [cla rule-check](https://docs.clarive.com/en/hcl/cli/) lists what a save from the view would change in each rule of an installation, and it is worth running first. ## One step at a time Double-clicking an operation in the tree opens its dialog, which now has an HCL tab after Note. It shows that one step as it would read in the rule file, without its children, which stay in the tree. The text is built from the dialog, not from the stored step. Anything changed in the Config, Options, Root-Cause Analysis or Note tabs and not yet applied is already in it, laid out as Apply would store it. The text flows one way, from the tabs into HCL. Coming back to the HCL tab reads the other tabs again, unless the text has edits of its own. Apply sends the text to the server, which checks it and lays it over the dialog's values, and the result becomes the step exactly as a form Apply would make it. Nothing is stored until the rule itself is saved, so the rule's own save and versioning still apply. A step with errors isn't applied, and the dialog stays open. The tab is stricter than a rule file. It holds exactly one step, and a nested block is refused instead of silently dropped. The operation can't change either. A shell step can switch between running locally and on a server, but an `if` stays an `if`. ## Resources, roles and groups The same text appears on the screens where objects are administered. The resource editor has an HCL tab, editable exactly when the properties form is. The role detail screen has an HCL tab too, and on the user group grid each row has an HCL action that opens the group in a window. Edits made on a resource's other tabs show up in its HCL tab before they are saved, and a banner points that out. Saving from the HCL tab stores everything shown, and the form is rebuilt from what was stored. Credentials appear in the base64 form the files use, and another banner explains that leaving a value out keeps the one already stored. The editor won't save text that describes a different object. Pasting another server into a server's tab gets this message: ```text This is generic_server.other, but the editor is open on generic_server.web01 ``` Renaming the object in the text is allowed. Missing references are always an error in the browser, and there is no equivalent of the command line's `--prune` or `--allow-missing`. Users are the exception. They can be viewed as HCL from the user grid but not edited there. Everything else on the user screen that changes a user has a side effect the record doesn't carry. Inviting someone sends mail, suspending an account ends its sessions and a password change sends a notification. A save from text would write the same fields and do none of that, so someone setting `active = false` would reasonably expect a suspension that never happened. Roles and groups have no actions like those, which is why they can be edited in the browser. `cla import` is the way to move users between installations. The browser remembers, for the page it is running in, whether you last left a rule, a step or a resource on its HCL view, and opens the next one the same way. Reloading the page forgets it. ## What the browser doesn't cover HCL in the interface covers rules, resources, roles, users and user groups. Topics and the six kinds of object that can't be written as files yet have no HCL view. Whole-configuration work, including moving objects between installations and pruning what the files no longer mention, stays on the command line. The full description of each view is in the [interface documentation](https://docs.clarive.com/en/hcl/ui/). If you'd like a walkthrough of the HCL views on your own rules, [get in touch](https://clarive.com/contact).