> For the complete documentation index, see [llms.txt](https://docs.enate.net/enate-help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.enate.net/enate-help/builder/builder.md).
# Builder
Enate's Builder module is for business analysts and people within your Center of Excellence where they can configure the processes that make up a service.
## Overview of Builder
Enate Builder allows you to deploy and configure new Services, Cases and Tickets for your customers quickly and easily. It allows you to set up standard reusable configurations which help support repeatability in your Service delivery.
This following sections will describe the features available to allow you to view the Services your customers receive (and which components of that Service are switched on for them, i.e. specific Cases and Tickets), configure these Cases and Ticket settings, create standard patterns of settings to be re-used, build Flows, and move these items from draft through to live operating business processes.
Here's a quick video that will introduce you to Builder:
{% embed url="" %}
## Accessing Builder
You can access Builder by first logging into [Work Manager](/enate-help/work-manager/work-manager.md). If you have been set up with ‘Can access Builder’ in your user setup (done by your user administrator, see [here ](/enate-help/builder/builder.md#c-different-levels-of-access-in-builder)for more details), then you will have access to Builder from the navigation menu. This will open Builder up in a separate window.
## Setting Levels of Access in Builder and Work Manager
These can all be found in the the 'Access' tab of the Edit User popup in the ‘See More’ section of an individual user in the [User Management Screen](/enate-help/builder/builder/user-management.md).
The breakout of permission levels for a user to access Builder is as follows:
### Can Edit Shared Configuration
This setting allows the user to modify core settings and shared data which are used in multiple places and so can have more wide-reaching impact when modified, as well as access to the following levels of configuration:
* Add/Edit Service Line
* Add/Edit Case/Ticket Archetype
* Add/Edit Action-Type in Global Menu
* Add/Edit/Clone of Flavors i.e. Due Date, Allocation, Action general, Ticket Follow Up
* Add/Edit Ticket Category Global List
* Add/edit Global Checklists
* Add/Edit Service Provider
* Add/Edit System Setting
* Add/Edit Calendar
* Add/Edit Custom Data and Fields
* Add/Edit Email Settings
* Add/Edit Schedule Structure
### Can Access User Management
This setting allows you to specifically access the User Management and RPA Integration sections.
### Can Set Live
You can use this attribute to help support segregation of capabilities - allowing you to specify that people who build processes in Builder aren't necessarily the same people who can set those processes live. This supports the existence of a 'Release Manager' role. This setting allows the user to access the following levels of configuration:
* Add/Edit Language translation
* Add/Edit Contract
* Add/Edit Service
* Add/Edit Case/Ticket into a Service
* Add/Edit Local checklist
* Add/Edit Customer
* Add/Edit Fixed Frequency Schedule
* Add/Edit Schedule records to Set Live and Retire
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.enate.net/enate-help/builder/builder.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.