GitLab

Overview

The GitLab destination lets you automatically create GitLab issues every time someone submits feedback through your forms. Whether you're tracking bug reports, feature requests, or general customer sentiment—GitLab triggers ensure that every piece of feedback gets turned into a trackable issue in your project, so nothing slips through the cracks.

This guide walks you through the full setup, from creating your first GitLab destination to customizing how those issues look, what labels they get, and how the description is formatted. We'll keep things straightforward and explain each step along the way so you can get up and running without any guesswork.

What You'll Need

Before you start, make sure you have:

• A feedback configuration — The form or feedback stream you want to send to GitLab
• A GitLab account — Access to GitLab.com or your self-hosted GitLab instance
• A Personal Access Token — With API scope, so encatch can create issues on your behalf
• A GitLab project — The project where you want issues to be created (you'll need its ID or full path, e.g., group/subgroup/project)

If you're not sure how to create a Personal Access Token, go to your GitLab profile → Access Tokens, create a new token with api scope, and use it when configuring your GitLab destination. Keep it secure—treat it like a password.

Step 1: Open the Destinations Page

Head to the Destinations section in your encatch dashboard. This is where you manage all your integration endpoints—Slack, Email, Jira, Webhooks, and of course, GitLab.

On the Destinations page, you'll see a table showing any destinations you've already set up (or an empty table if you're starting fresh). In the top-right corner, look for the Add Destination button—that's your starting point.

Click Add Destination to open the configuration flow.

Step 2: Add a New Destination

A modal will appear. You'll notice a field for Destination Description at the top—this is where you describe what this destination is for. Enter something like "Git triggers configuration" or "Create GitLab issues for product feedback" so you can easily identify it later.

Select from Available Destination Connectors

Scroll down to the section Select from available destination connectors. You'll see a table listing the available connectors: Email, GitLab, Jira, Slack, and Webhook.

Find the GitLab Notification row:

• TYPE: GitLab (with the GitLab icon)
• NAME: Gitlab Notification
• DESCRIPTION: Send Notifications to Gitlab as issues
• VERSION: v1

Click the Select button next to GitLab Notification to choose it as your connector. Once selected, the button will turn purple and show Selected.

Then click Create Destination at the bottom of the modal to proceed.

Step 3: Configure Your GitLab Destination

After creating the destination, you'll land on the configuration page. This is where you set up all the details that control how and where your GitLab issues are created.

Destination Details (Left Column)

On the left, you'll see cards for:

• Connector Configuration — Shows "Gitlab Notification" and its description
• Destination Name — Edit the name you gave earlier if needed (e.g., "Dest git")
• Destination Description — Edit the description if needed
• AI Filter — Optional section to filter which feedback creates issues

Click Save Details when you're done with these fields.

GitLab Configuration (Right Column)

The right side is where the GitLab-specific settings live. These are the credentials and project details encatch needs to create issues in your GitLab instance.

GitLab Host

Enter the base URL of your GitLab instance. For GitLab.com, use https://gitlab.com. For self-hosted GitLab, use your organization's GitLab URL (e.g., https://gitlab.yourcompany.com). This field is required.

Access Token

Enter your GitLab Personal Access Token with API scope. This is used for secure authentication—encatch never stores your GitLab password. Create one from your GitLab profile → Access Tokens if you haven't already. The value will be masked for security once saved.

Project ID or Path

Enter the GitLab project ID or full path to your project. For example: group/subgroup/project or a numeric project ID. You can find this in your project's settings or in the project URL. This field is required.

Step 4: Configure Issue Fields

Below the connection settings, you'll find the fields that control how each GitLab issue is created when feedback arrives. These let you map feedback to the right content and structure.

Issue Title

This is the main subject or headline of the GitLab issue. You can use a static value like "Feedback response" or use template variables to pull in dynamic content from the feedback (e.g., the user's summary or first response). This field is required.

Issue Description

This is a large text area where you define the body of the GitLab issue. The description supports Markdown and uses a templating language (Jinja-style) to inject feedback data dynamically.

A typical structure might look like:

## Feedback Summary

{% for question in questions %}
### **{{ question.title | default(value="Not filled") }}**

{% if question.type == "rating" %}
{% if question.value.selected is defined %}
- Rating: **{{ question.value.selected | default(value="Not filled") }} / {{ question.value.numberOfRatings | default(value="Not filled") }}**
{% else %}
- Not filled
{% endif %}
{% elif question.type == "short_answer" or question.type == "long_text" %}
- {{ question.value | default(value="Not filled") }}
{% elif question.type == "single_choice" %}
- {{ question.value.label | default(value="Not filled") }}
{% elif question.type == "multiple_choice_multiple" %}
{% if question.value is defined and question.value is iterable and question.value | length > 0 %}
- Answers: {% for item in question.value %}{{ item.label }}{% if not loop.last %}, {% endif %}{% endfor %}
{% else %}
- Not filled
{% endif %}
{% endif %}
{% endfor %}

This template loops over feedback questions and formats each one based on its type—ratings, short answers, long text, single choice, and multiple choice. Whatever you put here will become the content of the GitLab issue, so you can include feedback responses, device info, timestamps, and other metadata for full context.

Issue Labels

Add comma-separated labels to organize and categorize your feedback issues. For example: feedback, urgent, customer-reported. Use labels that already exist in your GitLab project so you can filter and search effectively.

Click Save Configuration when you're done.

Step 5: Enable the AI Filter (Optional)

If you want to filter which feedback triggers a GitLab issue, you can enable the AI Filter.

The AI Filter uses natural language prompts to decide which feedback should be forwarded to GitLab. For example, you might only want to create issues for negative feedback, or for feedback that mentions specific keywords like "bug" or "crash."

To enable it:

1. In the AI Filter section, click Test and Enable AI Filter
2. Configure your prompt to define the criteria
3. Test the filter with sample feedback to ensure it behaves as expected

If you prefer to create a GitLab issue for every feedback response, you can leave the AI Filter disabled.

Step 6: Test and Enable

Before going live, test your setup. On the Destination Status card, click Test & Enable Destination to verify your GitLab credentials work and that encatch can successfully create a test issue. Once the test passes, the destination will be enabled and will start creating real issues for every new feedback response that matches your configuration (and any AI filter you've set up).

Test Template Output

To preview exactly how your GitLab issues will look with real feedback data, use the Test Template Output feature. This lets you:

1. Load sample feedback data (or use the most recent record from the last 7 days)
2. Edit the Issue Description Configuration to refine your template
3. Click Execute Process to see the generated output
4. Adjust your template until the output looks right

You can toggle between Test Template (to preview the formatted output) and Test Connector (to verify the GitLab connection). This is especially useful for making sure your title, description, and labels are pulling in the right data from your feedback forms.

Summary

Here's a quick recap of the flow:

Tips and Best Practices

• Use descriptive labels — Labels like feedback, in-app, or urgent help your team triage and filter issues quickly.
• Leverage the description template — Include device info, URL, and user context so developers have everything they need without digging for it.
• Test before enabling — Always run a test to ensure credentials work and templates render correctly.
• Consider AI filters — If you receive a lot of feedback, an AI Filter can reduce noise by only creating issues for feedback that meets your criteria.
• Use the full project path — For nested groups, the full path (e.g., group/subgroup/project) is often clearer than a numeric ID.

Troubleshooting