> For the complete documentation index, see [llms.txt](https://docs.editran.onesait.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.editran.onesait.com/documentacion-editran/publico-editranff-v6.2-windows-en/administrador-de-onesait-ecosystems-editran-ff/alta-de-perfiles/alta-o-asociacion-de-usuarios-a-una-aplicacion.md).

# Create or associate users to an application

This operation can be carried out by selecting the user in the tree and dragging it to the destination application, or by selecting the user in the view: “Editran/FF Users”, “Editran/FF Local Users” or “Editran/FF Remote Users” and likewise dragging it to the destination application.

From any of these options the program asks:

![](https://content.gitbook.com/content/AKp9o4ESamTHpX42EKdv/blobs/g5E8FtNlslhvN3SnhQ9V/image1.png)

If the answer is yes, depending on the type of user and the type of application, the dialogs described below are shown.

Local User in signing application:

![](https://content.gitbook.com/content/AKp9o4ESamTHpX42EKdv/blobs/Pt4qvbYUmR1p4vJEIofq/image2.png)

* **User:** associated user name. This parameter is not editable.
* **Group:** if the user in the application is part of a group, its name is shown here (in the section **4.2.4** you will see how to create groups in applications and in **4.2.5** how to add application users to the group. This parameter is not editable.
* **Application:** name of the application to which the user has been associated. This parameter is not editable.
* **Viewer and validator:** name of the executable module with which the data files that are to be signed are validated and displayed. The combo box includes all viewer and validator modules included in the product and will show by default the same one that was chosen for the application. Both must always match except when the viewer to be used is the Transfer standard (both in flat format and in XML format). In this case, the Summary program must be specified at application level and **only in this profile and for the corresponding users, the HR version will be indicated. The HR version allows the user to view the full content of the files and, therefore, the individual transfers.**
* **Maximum total amount allowed in the files (€):** is the total amount of the application files that this user can sign at most.
* **Signature level:** through this parameter the application can regulate the order of the signers. There are five levels, with level 5 referring to the signer lowest in the hierarchy and so on up to level 1, which will correspond to the user with the highest rank in the structure and who will be the last to sign. There may be more than one user at the same level in the application. The combo box will appear enabled if “*Enable signer order” was marked in the application.*
* **Next signer:** when the associated user described in this dialog signs a file, and as long as the sending of e-mails has been configured, the user selected in this combo box will receive a notification informing them that they can now sign said file.
* **Move/reject/delete files:** this field gives the user permission to move, reject and delete files whenever they deem it necessary.
* **Enable sending when all signatures are present:** this parameter and the next one refer to the permission granted to the user regarding enabling the application. If this first field is activated, the user will be able to enable the sending of the application as long as all the application files have all the necessary signatures and all of them are correct.
* **Enable sending even if signatures are missing (forcefully):** this field is displayed only when the previous one has been activated. Selecting it implies granting this user permission, in addition, to enable the application, in any case, even if signatures are missing.

The following fields appear enabled only when the signing mode selected in the application is of the XAdES type, they are optional. If filled in, this information will appear in the corresponding nodes of the resulting signature:

* **SignatureProductionPlace:** is the physical place where the signature is made. The city, province, postal code and/or country can be filled in.
* **SignerRole:** collects the role that the signer has in the organization.
* **CommitmentTypeIndication:** collects the action of the signer on the document.

Local user in application to verify:

![](https://content.gitbook.com/content/AKp9o4ESamTHpX42EKdv/blobs/8y90ttsrxN5iBEOpaKJ7/image3.png)

In addition to the name of the user and the application to be related, the fields shown are:

* **When all signatures are present:** if this field is selected, the user will be able to accept the received application as long as all files have the necessary signatures and all are correct.
* **Even if signatures are missing:** this field appears only when the previous one has been activated. Selecting it implies granting this user permission to accept the application, in any case, even if signatures are missing or some of the received ones are incorrect.

No dialog appears for remote users, since their profiles only consist of the user and application names.

In all cases the new Application-User relationship will be stored in the file “*aplicgroupuserff.cfg*” and a new branch of the application will appear in the tree under the “*Local endpoint*” or the “*Remote branch*” depending on the type of user.


---

# 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.editran.onesait.com/documentacion-editran/publico-editranff-v6.2-windows-en/administrador-de-onesait-ecosystems-editran-ff/alta-de-perfiles/alta-o-asociacion-de-usuarios-a-una-aplicacion.md?ask=<question>&goal=<user_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.
