space.vars.OIM. This user shouldn't perform any other action from Polarion's user interface.
* Following are the user privileges required:
1. The user must have access to the default SVN repository:
* To grant user access to the default repository, refer [Grant Permission To Access Repository](#grant-permission-to-access-repository).
2. The user must have the role of '**project\_admin**' in the project which they are going to configure in space.vars.OIM.
* To assign this role, refer [Assign Role To User](#assign-role-to-user).
3. The user must have the following minimal permissions:
| Access Level | READ Permissions | WRITE Permissions |
| ------------------ | ------------------ | -------------------------------------------------------------------------------------------------------------------- |
| Projects | Permission to VIEW | Permission to VIEW |
| REST API Endpoints | Permission to GET | Permission to GET
Permission to PATCH
Permission to POST
Permission to DELETE (For attachments only)
space.vars.OIM.
Refer to [System Configuration](/v7.237/integrate/configure-integrations/system-configuration.md) for steps on how to configure the system. Refer to the screenshot below:
Provide the Server URL of the Polarion instance.
Format: http\://\[host name]:\[port no] or http\://\[your\_domain\_name].
Example:
Provide the Personal Access Token for the user specified in the "User Name" field.
Refer to Access API Token section for details.
Provide link metadata for Polarion workitem type in JSON format. For more details refer to Link Metadata Configuration.
This same field is also used to declare custom fields for the Plan entity (refer to Plan Field Configuration) and to override the data type of Rich Text custom fields on a Test Run (refer to Test Run Field Configuration).
Provide a different instance URL of the Polarion instance. This URL will be used for generating the Remote Link.
Note: If "Base URL for Remote Link" is empty, it will use default Instance URL to generate remote link if configured on integration.
space.vars.OIM as shown in image below.
space.vars.OIM.
* For example, if your custom column has an internal ID *customColumnId*, you can access it under *additionalFields*.
* Values stored in *additionalFields* can also be reused in other mappings (e.g., **description, expected result, or other supported fields**), helping you avoid duplicate mapping logic.
* Example XSLT:
```xml
space.vars.OIM's mapping screen. |
| `dataType` | The field's type. Supported values: `text`, `numeric`, `boolean`, `date` , `date_string`, `lookup`, `html`, `wiki`, `user`, `link`, `reference`. |
| `mandatory` | Set to `true` if the field is required in Polarion. Defaults to `false`. |
| `readOnly` | Set to `true` if the field cannot be written to. Defaults to `false`. |
| `systemSpecific.systemNativeDataType` | Only needed for rich text fields — set to `richText` so the value is sent to Polarion as HTML. |
| `lookUpValues` | Only needed when `dataType` is `lookup` — a list of `"space.vars.OIM cannot tell the two apart on its own. If a Test Run custom field is Rich Text in Polarion, you must override its data type in the **Metadata JSON** field on the Polarion system form so it is synchronized as HTML instead of plain text.
#### Understanding Metadata JSON Input for Test Run Rich Text Fields
This JSON is to be added in system form. Refer to section [System Form configuration](#Polarion-System-Form-Details) Add an entry for the field under `entities` → `testRun` → `fields` → `custom`, with `dataType` set to `html`:
```json
{
"entities": [
{
"internalName": "testRun",
"fields": {
"custom": [
{
"internalName": "customRichText",
"dataType": "html",
"systemSpecific": {
"systemNativeDataType": "richText"
}
}
]
}
}
]
}
```
| Property | Description |
| ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `internalName` | Internal name (id) of the Rich Text custom field, exactly as configured in Polarion. Refer to [Get Custom Fields for Test Run](#get-custom-fields-for-test-run) to find this value. |
| `dataType` | Set to `html` to override the field's discovered type. |
| `systemSpecific.systemNativeDataType` | Set to `richText` so the value is sent to Polarion as HTML. |
> **Note**: Only fields that are Rich Text in Polarion need to be listed here.
#### Template Field
The **Template** field of a Test Run can only be set when the Test Run is created — Polarion does not allow it to be updated later. While mapping the Template field, set its **Sync When?** option to **Create** (not the default **Both**). Refer to [Sync When](/v7.237/integrate/configure-integrations/mapping-configuration.md#sync-when) for steps.
> **Note**: If **Sync When** flag is configured as **Both**, every update sync for that Test Run will fail with a Polarion error.
## Integration Configuration
Set a time to synchronize data between Polarion and the other system. Define parameters and conditions, if any, for integration.
Refer to [Integration Configuration](/v7.237/integrate/configure-integrations/integration-configuration.md) for step-by-step instructions.
space.vars.OIM:
#### Sample criteria:
| Field name | Field internal name | Criteria description | Criteria snippet |
| ------------ | ------------------- | ------------------------------------------------------ | ------------------------------------- |
| Title | title | Sync items with title containing "API" | (title:\*API\*) |
| Status | status | Sync items where status equals "Open" | (status:open) |
| Created Date | created | Sync items created between 1 June 2025 to 30 June 2025 | (created:\[20250601 TO 20250630]) |
| Status | status | Sync items where status is not reviewed | (NOT status:reviewed) |
| Severity | severity | Sync items where severity is either normal or blocker | (severity:normal OR severity:blocker) |
### Target LookUp Configuration
* Provide query in Target Search Query field such that it is possible to search the entity in the Polarion as the target system. In the target search query field, you can provide a placeholder for the source system's field value in the '@'.
* To learn in detail about how to configure Target LookUp, refer to **Search in Target Before Sync** section on [Integration Configuration](/v7.237/integrate/configure-integrations/integration-configuration.md) page.
* Overall, Target LookUp Query is similar to [Criteria configuration](#criteria-configuration), except that the value part contains a field name with '@' instead of static value.
* While adding the query, user needs to add the internal names of the fields on which the query is to be applied.
#### Sample target lookup query:
| Field name | Field internal name | Target Lookup use case | Query snippet |
| -------------- | ------------------- | ------------------------------------------------------------------------------------------- | ------------------------------- |
| Target Item ID | targetItem | Target Lookup on the item having the source entity's id in custom field called 'targetItem' | targetLookup:@oh\_internal\_id@ |
## Known Behaviors and Limitations
* History based synchronization is not supported due to API unavailability.
* **Comments**:
* Replies to comments or edits in Polarion will be synced as separate comments by space.vars.OIM.
* **Project Groups**:
* Project Groups are not visible in the Project mapping list due to API limitations; projects are listed individually.
* **Test Steps sync**:
* If your test steps contain custom columns, or if standard columns have been renamed \[like Expected results renamed as Results], then advanced mapping needs to be performed in space.vars.OIM to sync those values. For more details, refer to this section [Known Behaviors in Test Step Sync](#known-behaviors-in-test-step-sync).
* **Links**
* For link synchronization it is required to provide link metadata for Polarion entity types in JSON format in OpsHub Integration Manager.
* Reason: API unavailability.
* The Suspect and Revision properties of a link will not be explicitly synchronized due to API limitations as these properties are auto-populated by Polarion when links are added.
* **Plan**:
* Attachments and comments are not supported for Plan, as Polarion does not provide them for this entity.
* Custom fields on a Plan must be declared using the Metadata JSON field, since Polarion provides no API to fetch them. Refer to [Plan Field Configuration](#plan-field-configuration).
* **Test Run**:
* Polarion reports a Rich Text custom field the same way it reports a plain text one, so a Rich Text custom field on a Test Run must be declared in the Metadata JSON field, otherwise it will be synchronized as plain text instead of HTML. Refer to [Test Run Field Configuration](#test-run-field-configuration).
## Appendix
### Grant Permission To Access Repository
To make sure the user (Example, ID = automationtest) has access to the SVN repository:
* Update the 'access' file located at `@POLARION_INSTALLATION_PATH@\data\svn`, add the following entries:
```ini
# Append automationtest to existing lists
[groups]
user = ..., automationtest
[/]
automationtest = rw
[repo:/]
automationtest = rw
[repo:/.polarion/access]
automationtest = rw
```
### Assign Role To User
To assign user the role of 'project\_admin':
1. Log in to your Polarion account as admin.
2. Go to the 'Administration' section by clicking on the settings icon in the top left-hand corner of your screen. Refer to the screenshot below:
3. Click 'User Management' -> 'Users' in the left pane. Refer to the screenshot below:
4. In 'Project Roles', give the user 'project\_admin' role. For example, refer to the screenshot below for Role assigned to the user in Project 'Automation\_Unit\_Project':
### Check API Permissions Required To give user the relevant permissions that allows synchronization of entities: 1. Log in to your Polarion account as admin. 2. Go to the 'Administration' section by clicking on the settings icon in the top left-hand corner of your screen. Refer to the screenshot below:
3. Now, go to 'User Management' -> 'Permissions Management' -> 'By Role'. Here, make sure the following permissions are checked.
### Get API Token To get the API token for a user: 1. Log in to your Polarion account. 2. Go to the 'My Account' section by clicking on the settings icon in the top left-hand corner of your screen. Refer to the screenshot below:
3. Click 'Personal Access Token' in the top pane and copy the token value. Refer to the screenshot below:
space.vars.OIM.
### Access Field Internal Name
To get the field internal names:
1. Log in to your Polarion account.
2. Go to the 'Administration' section by clicking on the settings icon in the top left-hand corner of your screen. Refer to the screenshot below:
3. Click 'Work Items' -> 'Custom Fields' in the left pane. Refer to the screenshot below:
--- # 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.opshub.com/v7.237/connectors/polarion.md?ask=