# Jira Airdrop

Import or sync Jira projects for a seamless DevRev onboarding experience.

## **Overview**

![image](https://user-images.githubusercontent.com/16090899/184037723-ae5ed2be-4ec6-4c99-9872-751cea9a7b2c.png)

Jira Airdrop lets you track your work, no matter where it happens. Migrate your projects, and users for a seamless onboarding experience or keep your issues in sync, allowing you to leverage both systems.

## **How it works**

Jira Airdrop offers various ways to import and sync issues and users from Jira. You can import a single project or as many as you want, you can keep a 1-way sync to DevRev or keep both systems in sync.

## **Features**

**Recipe Mapping**

With recipe mapping, you can be sure you won't miss out on the important Jira fields, even if they are custom. You choose what to migrate and let our reccomendations guide you on how best to migrate over your Jira projects.

**Import**

The import options lets you migrate a Jira project for an easy 1-time bulk import. This option leverages recipe mapping, so you will bring over only what matters and leave the baggage behind.

**Sync to DevRev**

With Sync to DevRev, you can resync a previous import to pull in any new issues or changes to previously imported issues from a Jira project.

**Sync to Jira**

The Sync to Jira feature lets you write back changes made in DevRev to previously imported Jira projects. You can optionally also sync new work items created in DevRev to Jira.


Jira Airdrop

Import or sync Jira projects for a seamless DevRev onboarding experience.

# GitHub autonomous work
Sync GitHub and DevRev so issue status is always real time and driven by code.
## **Overview**

<img src="https://raw.githubusercontent.com/shashankcube/image/main/github-automation.png" align="center"/> 
 
Connect GitHub with DevRev, and ensure your work stays in sync between the two systems, such that issues and statuses are always real-time and driven by code activity. GitHub autonomous work is a predefined automation that has been used by several organizations, and ties DevRev issues closely with Git activities, eliminating the need for humans to manage issues.

Why should you un-manage your work? You should use this automation if you want to reduce work about work. Let machines manage issues, including creating and updating statuses, so developers can focus on work that matters. You’ll resonate with this, if you have ever:

- Delivered a hot-patch and realized you never had an issue to track it
- Wasted time just updating your team on the status of an issue
- Or just felt that creating and managing issues is a distraction

If your team’s best practice is to link your GitHub activity to an existing issue-ID during branch creation, commits and PRs, then this automation will honor that and enable a GitHub driven issue state, without auto creating issues. [Here](https://devrev.ai/docs/integrations/github#github-events) are the different ways you can link your DevRev issue to GitHub branches, commits and PRs. 

However, if you choose to work in GitHub and never created or linked an issue, you shouldn’t have to sweat it. This automation will automatically create issues that track all associated commits, branches and pull requests. The auto-created issue is enriched with PR description and related GitHub events. The status of these issues is driven by GitHub activity, and the issues will auto-transition stages, from In Development to In Review, and Closed. Your work is always accounted for and more importantly your team members have visibility and know what you’ve been up to, resulting in fewer interruptions. 

## **How it works**

To enable GitHub autonomous work, click on Install and we'll walk you through a few simple steps including connecting with GitHub. You'll have a default set of configuration settings and the option to further personalize this automation. Learn more about the features in this automation.

## **Features** 
This automation is powerful, and has several configurable features. As they say, the power is in the defaults! When you install this Flow, we'll configure defaults that are tried and tested. You always have the option to personalize further.

**Automatic status updates**

You can associate GitHub commits, branches and pull requests with the DevRev issue they correspond to. Doing so allows you to see GitHub activity in the corresponding DevRev issue and to act on those events, allowing you to automate away your manual tasks. Mention DevRev issues in GitHub, and route the relevant GitHub events to this issue. They can be mentioned either as display IDs (ISS-34) or object IDs (issue:34), case insensitively. A DevRev issue can be mentioned in branch names, commit messages or PR titles.

**Autocreate issues from GitHub branch**

If you do not explicitly associate your DevRev issue to GitHub branches, commits or PRs, then we can autocreate your issues so you have an account of all your GitHub activity. This feature automatically creates an issue when a new branch is created, and tracks all associated commits and Pull Requests on this issue. The auto-created issues will move status based on Git activity, to in development based on branch and commit activity, and in review when PRs are created and merged. If desired, when PRs are merged, you can personalize the automation to move the issue to closed status. However, this template by default will keep the issue in an open state.

**Autocreate issues from GitHub PRs**

You can choose to automatically create issues when a new PR is created, and it is not linked to an existing DevRev Issue. The behavior is similar to how issues are auto-created with new branches. The auto-created issues will move status based on Git activity, and events are posted on the DevRev issue timeline. If desired, when PRs are merged, you can personalize the automation to move the issue to closed status. However, this automation by default will keep the issue in an open state. It is recommended you enable either one of `Autocreate issue from GitHub branch` or `Autocreate issue from GitHub PR`, but not both.

Issues autocreated from GitHub branches or PRs are called autonomous issues, and have the tag `autonomous`.

**Attribute part to autonomous work**

Autonomous issues originating from GitHub will be attributed to a default part. You can configure the default\_part, while setting up your flow, Every issue on DevRev must have a Part attribution

**Enrich autonomous work descriptions**

Enrich autonomous issues with information derived from GitHub PR events. The title and description of an autocreated issue is enriched with the PR data. When a new GitHub PR is opened or edited, then the related autonomous issue description is updated with the latest PR description. If the user has removed the auto generated text, then the automation will no longer update the description from PRs. Similarly, autonomous work titles are updated with the PR title, if the user hasn’t already updated it.

**Link autonomous work with related issue**

Create a parent-child link b/w the work-items mentioned in the PR body and the autonomous issues tagged with the branch/PR. When a new GitHub PR is opened/edited, for all the autonomous tagged work items(by branch/PR), automatically make the issues mentioned in the PR as parents.


**Automatically close autonomous work**

Autonomous work gets closed when its related PR is merged. However, if there is no PR activity on this work, then the autonomous work is closed after configurable period.

## **Frequently asked questions** 
<details>
<summary>What is an autonomous issue?</summary> 
Autonomous issue is an issue created automatically from an external event, such as a new GitHub branch or PR. These issues have the tag <code>autonomous</code>.
</details>

<details>
<summary>How does an issue change status?</summary>

<table>
 <tr>
 <td></td>
 <td colspan="2" align="center">Stage</td>
 </tr>
 <tr>
 <td></td>
 <td>From</td>
 <td>To</td>
 </tr>
 <tr>
 <td>New branch</td>
 <td>Any but not closed status</td>
 <td>In development</td>
 </tr>
 <tr>
 <td>Commit pushed</td>
 <td>No change</td>
 <td></td>
 </tr>
 <tr>
 <td>PR opened</td>
 <td>Any but not closed status</td>
 <td>In review</td>
 </tr>
 <tr>
 <td>PR closed</td>
 <td>In review</td>
 <td>In development</td>
 </tr>
 <tr>
 <td>PR reopened</td>
 <td>Any but not closed status</td>
 <td>In review</td>
 </tr>
 <tr>
 <td>*PR merged (without /close)</td>
 <td>In review</td>
 <td>In development</td>
 </tr>
 <tr>
 <td>PR merged (with /close)</td>
 <td>Any but not closed status</td>
 <td>Resolved</td>
 </tr>
</table>
 *This change happens only when <code>change_stage_to_in_development_on_pr_close</code> is true

</details>

<details>
<summary>What are the autonomous work configuration options?</summary>

<table>
 <tr>
 <td>Parameter</td>
 <td>Value</td>
 <td>Description</td>
 </tr>
 <tr>
 <td><code>create_work_item_on_new_branch</code></td>
 <td>Enabled or disabled</td>
 <td>Creates autonomous work items on a new branch when no work-id is mentioned</td>
 </tr>
 <tr>
 <td><code>create_work_item_on_pr_open</code></td>
 <td>Enabled or disabled</td>
 <td>Creates autonomous work items on a new PR, when no work-id is mentioned</td>
 </tr>
 <tr>
 <td><code>mention_work_directly_in_pr_body</code></td>
 <td>Enabled or disabled</td>
 <td>Link work-id to a PR, when its found in PR body</td>
 </tr>
 <tr>
 <td><code>enable_magic_commands</code></td>
 <td>Enabled or disabled</td>
 <td>Use magic commands /close and /toward in your PR</td>
 </tr>
 <tr>
 <td><code>close_autonomous_work_on_merge</code></td>
 <td>Enabled or disabled</td>
 <td>Close the autonomous work when the PR is merged</td>
 </tr>
 <tr>
 <td><code>default_part</code></td>
 <td>part display id</td>
 <td>Autonomous work is created under this default part</td>
 </tr>
 <tr>
 <td><code>update_autonomous_work_from_pr</code></td>
 <td>Enabled or disabled</td>
 <td>Enrich autonomous work item title and description with PR data</td>
 </tr>
 <tr>
 <td><code>link_autonomous_issues_with_pr_mention</code></td>
 <td>Enabled or disabled</td>
 <td>Link the work item mentioned in PR to the autonomous work created</td>
 </tr>
 <tr>
 <td><code>change_stage_to_in_development_on_pr_close</code></td>
 <td>Enabled or disabled</td>
 <td>Autonomous work changes stage to `in_development` when a PR is closed</td>
 </tr>
</table>
</details>

<details>
<summary>How can autonomous work creation be disabled?</summary>
 You can disable the parameters <code>create_work_item_on_new_branch</code> and <code>create_work_item_on_new_PR</code> to not autocreate issues. If you choose to turn this off as an exception, you can choose to begin your branch name or PR title with nw-(e.g, nw-new-branch) 
</details>

<details>
<summary>How can you attribute a part to an autonomous issue?</summary>
This automation will infer the part from a repository, if possible. If not, the issue is created with a specified default part. 
</details>

<details>
<summary>When is the automous issue closed?</summary>
The autonomous work item is automatically closed when its source PR or a PR on its source branch is merged.
</details>

GitHub autonomous work

Sync GitHub and DevRev so issue status is always real time and driven by code.

## **Overview**

![image](https://user-images.githubusercontent.com/16090899/184038381-53100232-c5c9-4b33-98db-433f439a65de.png)

Have you ever?

* Configured some Github Actions and want your related work to get updated with these changes?
* Wasted time updating your team on the status of your work?
* Wondered if an issue you worked on was built successfully?

**Don’t sweat it!** This automation will fetch details about different workflows and jobs running in Github Actions, and link it to your DevRev issue. Your work is always accounted for and more importantly your team members have visibility and know what you’ve been up to, resulting in fewer interruptions.

## **How it works**

If you are using GitHub Actions to build or carry out workflows, DevRev will track the work related to that workflow and update the timeline of that work item.

## **Features**

**Automatic status updates**

Automatically updates the status of work items related to a job or workflow.

**Record successes and failures**

Record job and workflow results in the work items that triggered them.


GitHub Actions

Track the status of your build, and keep GitHub Actions in sync with your DevRev Issue.

# GitLab autonomous work

Sync GitLab and DevRev so issue status is always real time and driven by code.

## **Overview**

![image](https://raw.githubusercontent.com/shashankcube/image/main/gitlab%20automation.png)

Connect GitLab with DevRev, and ensure your work stays in sync between the two systems, such that issues and statuses are always real-time and driven by code activity. GitLab autonomous work is a predefined automation that has been used by several organizations, and ties DevRev issues closely with Git activities, eliminating the need for humans to manage issues.

Why should you un-manage your work? You should use this automation if you want to reduce work about work. Let machines manage issues, including creating and updating statuses, so developers can focus on work that matters. You’ll resonate with this, if you have ever:

- Delivered a hot-patch and realized you never had an issue to track it
- Wasted time just updating your team on the status of an issue
- Or just felt that creating and managing issues is a distraction

If your team’s best practice is to link your GitLab activity to an existing issue-ID during branch creation, commits and MRs, then this automation will honor that and enable a GitLab driven issue state, without auto creating issues. We can link your DevRev issue to Bitbucket activity, through mention of issue-ID in branches, commits and PRs.

However, if you choose to work in GitLab and never created or linked an issue, you shouldn’t have to sweat it. This automation will automatically create issues that track all associated commits, branches and merge requests. The auto-created issue is enriched with MR description and related GitLab events. The status of these issues is driven by GitLab activity, and the issues will auto-transition stages, from In Development to In Review, and Closed. Your work is always accounted for and more importantly your team members have visibility and know what you’ve been up to, resulting in fewer interruptions.

## **How it works**

To enable GitLab autonomous work, click on Install and we'll walk you through a few simple steps including connecting with GitLab. You'll have a default set of configuration settings and the option to further personalize this automation. Learn more about the features in this automation.

## **Features**

This automation is powerful, and has several configurable features. As they say, the power is in the defaults! When you install this Flow, we'll configure defaults that are tried and tested. You always have the option to personalize further.

**Automatic status updates**

You can associate GitLab commits, branches and merge requests with the DevRev issue they correspond to. Doing so allows you to see GitLab activity in the corresponding DevRev issue and to act on those events, allowing you to automate away your manual tasks. Mention DevRev issues in GitLab, and route the relevant GitLab events to this issue. They can be mentioned either as display IDs (ISS-34) or object IDs (issue:34), case insensitively. A DevRev issue can be mentioned in branch names, commit messages or MR titles.

**Autocreate issues from GitLab branch**

If you do not explicitly associate your DevRev issue to GitLab branches, commits or MRs, then we can autocreate your issues so you have an account of all your GitLab activity. This feature automatically creates an issue when a new branch is created, and tracks all associated commits and Merge Requests on this issue. The auto-created issues will move status based on Git activity, to in development based on branch and commit activity, and in review when MRs are created and merged. If desired, when MRs are merged, you can personalize the automation to move the issue to closed status. However, this template by default will keep the issue in an open state.

**Autocreate issues from GitLab MRs**

You can choose to automatically create issues when a new MR is created, and it is not linked to an existing DevRev Issue. The behavior is similar to how issues are auto-created with new branches. The auto-created issues will move status based on Git activity, and events are posted on the DevRev issue timeline. If desired, when MRs are merged, you can personalize the automation to move the issue to closed status. However, this automation by default will keep the issue in an open state. It is recommended you enable either one of `Autocreate issue from GitLab branch` or `Autocreate issue from GitLab MR`, but not both.

Issues autocreated from GitLab branches or MRs are called autonomous issues, and have the tag `autonomous`.

**Attribute part to autonomous work**

Autonomous issues originating from GitLab will be attributed to a default part. You can configure the default\_part, while setting up your flow, Every issue on DevRev must have a Part attribution

**Enrich autonomous work descriptions**

Enrich autonomous issues with information derived from GitLab MR events. The title and description of an autocreated issue is enriched with the MR data. When a new GitLab MR is opened or edited, then the related autonomous issue description is updated with the latest MR description. If the user has removed the auto generated text, then the automation will no longer update the description from MRs. Similarly, autonomous work titles are updated with the MR title, if the user hasn’t already updated it.

**Link autonomous work with related issue**

Create a parent-child link b/w the work-items mentioned in the MR body and the autonomous issues tagged with the branch/MR. When a new GitLab MR is opened/edited, for all the autonomous tagged work items(by branch/MR), automatically make the issues mentioned in the MR as parents.

**Automatically close autonomous work**

Autonomous work gets closed when its related MR is merged. However, if there is no MR activity on this work, then the autonomous work is closed after configurable period.

## **Frequently asked questions**

<details>
<summary>What is an autonomous issue?</summary>
Autonomous issue is an issue created automatically from an external event, such as a new GitLab branch or MR. These issues have the tag <code>autonomous</code>.
</details>

<details>
<summary>How does an issue change status?</summary>

<table>
 <tr>
 <td></td>
 <td colspan="2" align="center">Stage</td>
 </tr>
 <tr>
 <td></td>
 <td>From</td>
 <td>To</td>
 </tr>
 <tr>
 <td>New branch</td>
 <td>Any but not closed status</td>
 <td>In development</td>
 </tr>
 <tr>
 <td>Commit pushed</td>
 <td>No change</td>
 <td></td>
 </tr>
 <tr>
 <td>MR opened</td>
 <td>Any but not closed status</td>
 <td>In review</td>
 </tr>
 <tr>
 <td>MR closed</td>
 <td>In review</td>
 <td>In development</td>
 </tr>
 <tr>
 <td>MR reopened</td>
 <td>Any but not closed status</td>
 <td>In review</td>
 </tr>
 <tr>
 <td>*MR merged (without /close)</td>
 <td>In review</td>
 <td>In development</td>
 </tr>
 <tr>
 <td>MR merged (with /close)</td>
 <td>Any but not closed status</td>
 <td>Resolved</td>
 </tr>
</table>
 *This change happens only when <code>change_stage_to_in_development_on_pr_close</code> is true

</details>

<details>
<summary>What are the autonomous work configuration options?</summary>

<table>
 <tr>
 <td>Parameter</td>
 <td>Value</td>
 <td>Description</td>
 </tr>
 <tr>
 <td><code>create_work_item_on_new_branch</code></td>
 <td>Enabled or disabled</td>
 <td>Creates autonomous work items on a new branch when no work-id is mentioned</td>
 </tr>
 <tr>
 <td><code>create_work_item_on_pr_open</code></td>
 <td>Enabled or disabled</td>
 <td>Creates autonomous work items on a new MR, when no work-id is mentioned</td>
 </tr>
 <tr>
 <td><code>mention_work_directly_in_pr_body</code></td>
 <td>Enabled or disabled</td>
 <td>Link work-id to an MR, when its found in MR body</td>
 </tr>
 <tr>
 <td><code>enable_magic_commands</code></td>
 <td>Enabled or disabled</td>
 <td>Use magic commands /close and /toward in your MR</td>
 </tr>
 <tr>
 <td><code>close_autonomous_work_on_merge</code></td>
 <td>Enabled or disabled</td>
 <td>Close the autonomous work when the MR is merged</td>
 </tr>
 <tr>
 <td><code>default_part</code></td>
 <td>part display id</td>
 <td>Autonomous work is created under this default part</td>
 </tr>
 <tr>
 <td><code>update_autonomous_work_from_pr</code></td>
 <td>Enabled or disabled</td>
 <td>Enrich autonomous work item title and description with MR data</td>
 </tr>
 <tr>
 <td><code>link_autonomous_issues_with_mr_mention</code></td>
 <td>Enabled or disabled</td>
 <td>Link the work item mentioned in MR to the autonomous work created</td>
 </tr>
 <tr>
 <td><code>change_stage_to_in_development_on_pr_close</code></td>
 <td>Enabled or disabled</td>
 <td>Autonomous work changes stage to `in_development` when an MR is closed</td>
 </tr>
</table>
</details>

<details>
<summary>How can autonomous work creation be disabled?</summary>
 You can disable the parameters <code>create_work_item_on_new_branch</code> and <code>create_work_item_on_new_MR</code> to not autocreate issues. If you choose to turn this off as an exception, you can choose to begin your branch name or MR title with nw-(e.g, nw-new-branch)
</details>

<details>
<summary>How can you attribute a part to an autonomous issue?</summary>
This automation will infer the part from a repository, if possible. If not, the issue is created with a specified default part.
</details>

<details>
<summary>When is the automous issue closed?</summary>
The autonomous work item is automatically closed when its source MR or an MR on its source branch is merged.
</details>

GitLab autonomous work

Sync GitLab and DevRev so issue status is always real time and driven by code.

# GitHub PR reminder

Schedule reminders and never let your GitHub Pull Requests go stale.

## **Overview**

<img src="https://raw.githubusercontent.com/shashankcube/image/main/github%20pr%20reminder.png" align="center"/>

Stay on top of your code reviews by scheduling reminders when a PR is inactive for a certain period. You can enable this automation for all of your GitHub repos, or for specific repos. When you enable GitHub autonomous work, PR reminders are scheduled to be posted on linked issues. You may also enable the GitHub PR Task automation that creates a task for every PR.

## **How it works**

To use this automation, you'll need to connect your GitHub with DevRev so we can listen to PR events. When you install this flow, we'll walk you through a few simple steps to connect and setup your reminders. You can find more on the supported connection methods here.

## **Features**

Post reminders on your DevRev issues, when related GitHub Pull Requests are inactive for a certain period.

**Automatic PR reminders**

When a pull request is inactive for more than a specified number of days, then this automation will post a message in all related DevRev issues. You'll need to link your GitHub Pull Request to DevRev issue to enable these reminders. There are several ways to link your GitHub Pull Requests to DevRev Issues. You can do so by mentioning the DevRev issue-id in Pull Requests title or body, or mention it in the branch name or commit message. Reminders are also posted for issues created autonomously.

You can choose to setup the inactive period in number of days through the max_inactive_days setting.

## **Frequently asked questions**

<details>
<summary>What are the prerequisites for scheduling PR reminders?</summary>
This automation is triggered when Pull Requests are linked to DevRev issues. If you have not linked GitHub Pull Requests, then reminders will not be posted.
</details>

GitHub PR reminder

Schedule reminders and never let your GitHub Pull Requests go stale.

# GitHub commands

Enable quick actions to close or attribute a PR to DevRev issue(s) with slash command.

## **Overview**

<img src="https://raw.githubusercontent.com/shashankcube/image/main/github%20commands.png" align="center"/>

Use commands such as /towards and /close for quick actions and associating GitHub Pull Requests to DevRev issues.

## **How it works**

To use this automation, you'll need to connect your GitHub with DevRev so we can listen to PR events. When you install this flow, we'll walk you through a few simple steps to connect and setup this flow. You can find more on the supported connection methods here.

## **Features**

Use /commands in GitHub Pull Request descriptions to associate Pull Requests to one or more DevRev issues, and close issues.

**/towards command**

Relate GitHub Pull Requests to DevRev issues with a /towards command. Use the /towards <issue-id> command in the PR description to associate the related GitHub activity to the issue(s). This will ensure that the PR and issue are linked such that related events are posted and issue status is driven by GitHub events.

**/close command**

Close a DevRev issue with this command. When /close <issue-id> <issue-id> is used, the automation will close the issue(s) when the PR is merged. This is helpful when you intend to not close the issue(s), unless explicitly driven with this command.

**/close #work command**

Close linked DevRev issues with this command and the "#work" keyword, to close all related issues. The "#work" keyword means that the closure applies to all issues already associated with the Pull Request.

GitHub commands

Enable quick actions to close or attribute a PR to DevRev issue(s) with slash command.

## **Overview**

![image](https://github.com/shashankcube/image/blob/main/DevRev%20Email%20PLuG.png?raw=true)

Connect your support email with DevRev and ensure that your support conversations remain in sync between email and the PLuG support widget. Email integration is a predefined automation that has been used by several organizations and allows you to manage support conversations that come through email directly from the DevRev PLuG inbox eliminating the need to manage two inboxes.

Why should you integrate your support email? Organizations need to support multiple mediums of communication for their customers and despite being slow when compared to chat, email is still an important part of most support operations. This automation enables low friction customer support by providing a unified place to manage the conversations generated through email as well as the PLuG support widget.

This integration allows you to manage all end user communication from one place so you never have to leave the context of the conversation to create a ticket and communicate with your development team.

## **How it works**

To enable email integration, click on the Google Oauth connection and allow the DevRev app to send emails through your support email ID. Deploy the flow and set the forwarding address of your support email to the generated DevRev email address.

## **Features**

**Get Conversations from support inbox**

When your customer sends an email to your support email with which the email integration was deployed, a conversation will be created in your PLuG Inbox. From within the context of that conversation you can create tickets and add additional members to the conversation.
When the customer replies back to the email, a comment is added to that same conversation.

**Reply to Customer through Email**

Whenever a support team member replies to the conversation that was generated through email, an email will be sent with that reply to that customer through your integrated support email. The emails will be threaded based on the first email that the customer sent.

**Support for Attachments and Raw Email**

The attachments sent by the customer can be viewed in the PLuG inbox along with the comment. Also, you can add the attachments in the reply to any comment and it will be attached to the email that will be sent to the customer.

A raw email file will be attached to the comment in the PLuG inbox which was generated through the email. The raw email file can be downloaded and the actual email can be viewed.

**Edit Comment**

You can edit the comment in the PLuG inbox and an email will be sent to the customer notifying that a comment was edited along with the edited content.

**Add Rich Text**

You can add markdown text (bold, italic, highlight) in the comment and it will be sent to the customer with the appropriate formatting.

**Append Conversations to an Existing Ticket**

You can use the action menu to append a Slack message to an existing Ticket.

## **Frequently asked questions**

<details>
<summary>What are the supported email providers?</summary>
For now, email integration is supported only for GSuite accounts.
</details>
<details>
<summary>How are attachments handled?</summary>
If the file size exceeds the limit of 25MB (set by Gmail) or if there are more than 10 attachments in the comment, a preview link will be sent in the body of the email through which the attachments can be downloaded.
</details>

DevRev PLuG with email

Bring conversations into DevRev PLuG even when customers interact over email.

# CircleCI with DevRev

Sync DevRev issues with CircleCI and bring visibility into your workflow jobs.

## **Overview**

<img src="https://raw.githubusercontent.com/shashankcube/image/main/circleci.png" align="center"/>

See where your issues are in CI/CD pipeline by bringing in CircleCI events. Improve your processes, by making events which need attention visible to everyone in context of the issue, inside DevRev.

## **How it works**

To enable CircleCI automation, you need to setup a webhook to enable DevRev listen to events from CircleCI. Webhook Setup instructions are shown while you configure flows and you can also configure this flow.

## **Features**

This flow helps you to keep track of your issue's build progress

**Workflow and Job Updates**

You can associate workflow and job termination events in CircleCI to DevRev issues, if the git branch on which the tests are running is tagged to an issue

**Decide which events to capture**

Workflow or jobs events can be overwhelming. You can configure if you want only certain events to be populated on the issue's timeline. You can choose between “success”, “failed”, “error”, “canceled”, “unauthorized” events and decide which events the flow should listen.

CircleCI with DevRev

Sync DevRev issues with CircleCI and bring visibility into your workflow jobs.

# Slack with DevRev

Never leave your customers in the dark! Create DevRev tickets and keep customers up to date, without ever leaving Slack.

## **Overview**

![image](https://raw.githubusercontent.com/shashankcube/image/main/slack%20with%20devrev.png)

Enable Slack users to reduce context switching and interact with DevRev while within Slack. Create DevRev tickets or issues from Slack conversations and stay up to date.

## **How it works**

To use this automation, you'll need to connect your Slack with DevRev. When you install this flow, we'll walk you through a few simple steps to connect and setup your integration.

## **Features**

Connect with Slack and ensure your customer or internal conversations are always in sync with DevRev tickets and issues.

**Create tickets or issues**

Use the actions (three dots) menu to create a ticket or issue from an existing Slack conversation. When you use this action, your ticket or issue will be pre-populated with the title, description and link to the Slack conversation. This works on any channel and direct messages and threads.

**Link to existing tickets or issues**

You can link a Slack conversation to an existing DevRev ticket. Use the actions menu to browse and link to an existing ticket or issue. You will receive autosuggestions on existing similar tickets and issues so you can avoid creating duplicate ones.

**Preview record**

When you've integrated with Slack, we'll show you a preview of the DevRev URL anytime you post it in Slack. The URL unfurling will show you the title, description, status and owner. You'll also have the option to update fields such as owner and status.

**Ticket updates**

Updates on DevRev tickets can be posted in Slack, so conversations are in sync. If you have customer conversations over Slack, then this automation will enable automatic status updates.

**Conversation updates**

Specific updates from your Slack conversation may be pushed to the DevRev ticket or issue record. This is especially useful when you want to send customer input back to the developers!

**Append conversation to an existing ticket**

You can use the action menu to append a Slack message to an existing Ticket.


Slack with DevRev

Never leave your customers in the dark! Create DevRev tickets and keep customers up to date, without ever leaving Slack.


# Slack commands

Invoke DevRev with Slack slash commands and enrich your conversations.

## **Overview**

![image](https://raw.githubusercontent.com/shashankcube/image/main/slack%20commands.png)

Create and manage DevRev tickets or issues from Slack conversations using the /devrev command.

## **How it works**

To use this automation, you'll need to connect your Slack with DevRev. When you install this flow, we'll walk you through a few simple steps to connect and setup your integration.

## **Features**

Type /devrev commands into any Slack channel or direct message to launch quick actions such as creating, updating and viewing DevRev tickets and issues.

**Personal view of tickets**

With /devrev view ticket-id or issue-id, the user can display a preview of the work items. This view is private to the user that uses this command, and is not available for everyone on the Slack channel or direct message.

**Share ticket**

With /devrev show ticket-id or issue-id, the user can display a preview of the work items to everyone in that channel or direct message.

**View my tickets**

With /devrev my tickets and /devrev my issues, the user can get a preview of all tickets or issues owned by the user. This is only viewable by those that use this command.


Slack commands

Invoke DevRev with Slack slash commands and enrich your conversations.

# GitLab commands

Enable quick actions to close or attribute an MR to DevRev issue(s) with slash commands.

## **Overview**

![image](https://user-images.githubusercontent.com/16090899/186488904-bd0851e0-f249-4a9a-8652-c70643ea9de0.png)

Use commands such as /towards and /close for quick actions and associating GitLab Merge Requests to DevRev issues.

## **How it works**

To use this automation, you'll need to connect your GitLab with DevRev so we can listen to MR events. When you install this flow, we'll walk you through a few simple steps to connect and setup this flow. You can find more on the supported connection methods here.

## **Features**

Use /commands in GitLab Merge Request descriptions to associate Merge Requests to one or more DevRev issues, and close issues.

**/towards command**

Relate GitLab Merge Requests to DevRev issues with a /towards command. Use the /towards <issue-id> command in the MR description to associate the related GitLab activity to the issue(s). This will ensure that the MR and issue are linked such that related events are posted and issue status is driven by GitLab events.

**/close command**

Close a DevRev issue with this command. When /close <issue-id> <issue-id> is used, the automation will close the issue(s) when the MR is merged. This is helpful when you intend to not close the issue(s), unless explicitly driven with this command.

**/close #work command**

Close linked DevRev issues with this command and the "#work" keyword, to close all related issues. The "#work" keyword means that the closure applies to all issues already associated with the Merge Request.

GitLab commands

Enable quick actions to close or attribute an MR to DevRev issue(s) with slash commands.

# GitHub PR tasks

Code reviews are also work. Create a task for every GitHub PR and stay on top of your code reviews.

## **Overview**

<img src="https://raw.githubusercontent.com/shashankcube/image/main/github%20pr%20task.png" align="center"/>

Code reviews can be time consuming — we may not always account for this in planning which may lead to poor estimates and delays. Make sure your code reviews are tracked as tasks, so you can stay on top of them.

Create tasks when you are added as a reviewer on a PR. When you enable this automation, we’ll create a task corresponding to this code review. This task is embedded in the related issue, and can also be tracked under My Tasks.

## **How it works**

To use this automation, you'll need to connect your GitHub with DevRev so we can listen to PR events. When you install this flow, we'll walk you through a few simple steps to connect and setup your reminders. You can find more on the supported connection methods here.

## **Features**

Your code reviews are also work and need to be accounted for. Use this automation to create a task for every code review, and stay on top of your GitHub PR reviews.

**Automatic PR tasks**

When a pull request is requested or reopened, a DevRev task is created for you. In order for this automation to be triggerred, you'll need to link your Pull Requests to DevRev issues. If your PR is removed, merged or closed, then the Task gets deleted. However, if you submit your PR review, then the task is closed.

## **Frequently asked questions**

<details>
<summary>What are the prerequisites for creating PR tasks?</summary>
You'll need to connect your GitHub identity with DevRev identity, so we can attribute the tasks to your DevRev user identity. You can link your GitHub identity by going to DevOrg Settings → Account → External Identities → Link GitHub Account
.
</details>

GitHub PR tasks

Code reviews are also work. Create a task for every GitHub PR and stay on top of your code reviews.

# GitHub Airdrop

Import or sync GitHub issues and users for a seamless DevRev onboarding experience.

## **Overview**

![image](https://user-images.githubusercontent.com/16090899/184037594-e56bcfbd-01f4-402f-b884-d93cc2b47604.png)

GitHub Airdrop makes it easy to transition from using GitHub issues to managing your issues in DevRev. Once your issues are in DevRev, you can use the GitHub flows to continue receiving GitHub events and take advantage of smart automations.

## **How it works**

GitHub Airdrop offers various ways to import and sync issues and users from GitHub. You can import a single repository or as many as you want, you can keep a 1-way sync to DevRev or keep both systems in sync.

## **Features**

**Import**

The basic import allows you to perform a 1-time import of GitHub issues and users from one or more repositories.

**Sync to DevRev**

With Sync to DevRev, you can resync a previous import to pull in any new issues or changes to previously imported issues from a GitHub repository.

**Sync to GitHub**

The Sync to GitHub feature lets you write back changes made in DevRev to previously imported GitHub issues. You can optionally also sync new work items created in DevRev to GitHub.


GitHub Airdrop

Import or sync GitHub issues and users for a seamless DevRev onboarding experience.

# Bitbucket PR reminder

Schedule reminders and never let your Bitbucket Pull Requests go stale.

## **Overview**

![image](https://user-images.githubusercontent.com/16090899/185510485-7b6ae276-04d3-4f84-8b69-04b9ceef2518.png)

Stay on top of your code reviews by scheduling reminders when a PR is inactive for a certain period. You can enable this automation for all of your Bitbucket repos, or for specific repos. When you enable Bitbucket autonomous work, PR reminders are scheduled to be posted on linked issues. You may also enable the Bitbucket PR Task automation that creates a task for every PR.

## **How it works**

To use this automation, you'll need to connect your Bitbucket with DevRev so we can listen to PR events. When you install this flow, we'll walk you through a few simple steps to connect and setup your reminders. You can find more on the supported connection methods here.

## **Features**

Post reminders on your DevRev issues, when related Bitbucket Pull Requests are inactive for a certain period.

**Automatic PR reminders**

When a pull request is inactive for more than a specified number of days, then this automation will post a message in all related DevRev issues. You'll need to link your Bitbucket Pull Request to DevRev issue to enable these reminders. There are several ways to link your Bitbucket Pull Requests to DevRev Issues. You can do so by mentioning the DevRev issue-id in Pull Requests title or body, or mention it in the branch name or commit message. Reminders are also posted for issues created autonomously.

You can choose to setup the inactive period in number of days through the max_inactive_days setting.

## **Frequently asked questions**

<details>
<summary>What are the prerequisites for scheduling PR reminders?</summary>
This automation is triggered when Pull Requests are linked to DevRev issues. If you have not linked Bitbucket Pull Requests, then reminders will not be posted.
</details>

Bitbucket PR reminder

Schedule reminders and never let your Bitbucket Pull Requests go stale.

# Converge support and build

Unlock the power of a converged system of record, and ensure customer conversations, support tickets and development issues are always in sync.

## Overview

![image](https://user-images.githubusercontent.com/16090899/185511090-5c43797b-3bb0-47a9-bfc9-2560e909fd19.png)

Supercharge cross-functional work with this set of default automations, propagating information across various entities at DevRev - including Conversations, Tickets, and Issues.

DevRev's shared system of record opens up doors for 'the machine' to take over & intelligently ensure heartbeats from various functions of your DevRev workspace travel across each other.

'Convergence with DevRev' is a set of default automations that power cross-functional information flow in your DevRev workspace, such that updates from Product teams' Issues make way to Tickets in the 'front-office' and vice versa with little human intervention.
Let machines be the messenger of 'Updates' so they arrive before the next "Any progress on this?" or "What's the progress on this?".

## How it works

This set of Convergence automations will be enabled for you by default. Find them under Flows in your workspace settings, where you can adjust configuration to tweak app behaviour.
Find more details below on the first set of individual behaviours that this Flow includes.

## Features

This automation is powerful and has a series of individual, configurable behaviours.

As they say, the power is in the defaults! With this pre-enabled Flow come DevRev's tried and tested defaults. You always have the option to adjust further. You will soon have the option to further customize these automations, or write your own! :)

**Automatic Customer Updates from Tickets**

Propagate updates from Tickets to related customer Conversations, examples including -

- When a Ticket is closed, post an autonomous update to the related PLuG conversation (if any).
- When a Ticket is linked to a Conversation, autonomously update the Conversation & provide a follow-up reference to the customer.
- When a Ticket is updated with relevant information, post a heartbeat to the Conversation (so conversation owners )

So your customer is never in the dark.

**Automatic Updates between Tickets to Issues**

Leveraging the association between customer Tickets (for your Revs) and your Product team's Issues, this automation focusses on keeping Issues aware of changes to Tickets and vice-versa, with updates like -

- When a Ticket severity changes, autonomously update Issue Priority & Stage accordingly.
- When progress is made on Issues, update the status on dependent Tickets.
- When underlying Issues are resolved, advance Tickets to the next stage - making the baton-passing motion seamless.

So your Dev team never has to be "kept in the loop" manually.

**Autonomous Issue Management**

Parent Issues, Child Issues, Dependent Issues, Blocked Issues - are any Dev's nightmares.
With this set of autonomous Convergence behaviours, Issues and their hierarchy become a tad-bit manageable -

- Watch children Issues & automatically update a parent Issue when a Dev starts working on it.
- As children Issues make progress, send state updates to parent Issues along with information on 'completion progress'.
- Or when parent Issues are closed, update children Issues automatically reducing manual bookkeeping.

## **Frequently asked questions**

<details>
<summary>What does Convergence mean?</summary>

 DevRev's system of record converges multiple functions in an organization - touching everything from customer conversations, tickets and developer issues. Yet, because the system of record is shared, it paves way for the machine to take on menial, repetitive work - specially around bringing together (or _converging_) these cross-functional entities (and thus the teams that work on them) together.

 This set of automations is the first wave of machine-driven app behavior towards this **_Convergence_**.
</details>

<details>
<summary>Can these automations be disabled, completely or partially?</summary>
 All automation behaviours listed above are individual automations that can be turned on/off as per your team's workflow. 
 Configuration options for these adjustments would be visible under your Flows in your Org Settings.
</details>

<details>
<summary>Can I extend these automations in the future?</summary>
 Yes! The ability to tweak these flows (beyond currently available configuration options) & to write your own flows is on the roadmap, and will be available soon.
</details>

Converge support and build

Unlock the power of a converged system of record, and ensure customer conversations, support tickets and development issues are always in sync.

# Bitbucket commands

Enable quick actions to close or attribute a PR to DevRev issue(s) with slash commands.

## **Overview**

![image](https://user-images.githubusercontent.com/16090899/185509871-e4335c87-3445-45f6-bf46-61d8e689479a.png)

Use commands such as /towards and /close for quick actions and associating Bitbucket Pull Requests to DevRev issues.

## **How it works**

To use this automation, you'll need to connect your Bitbucket with DevRev so we can listen to PR events. When you install this flow, we'll walk you through a few simple steps to connect and setup this flow. You can find more on the supported connection methods here.

## **Features**

Use /commands in Bitbucket Pull Request descriptions to associate Pull Requests to one or more DevRev issues, and close issues.

**/towards command**

Relate Bitbucket Pull Requests to DevRev issues with a /towards command. Use the /towards <issue-id> command in the PR description to associate the related Bitbucket activity to the issue(s). This will ensure that the PR and issue are linked such that related events are posted and issue status is driven by Bitbucket events.

**/close command**

Close a DevRev issue with this command. When /close <issue-id> <issue-id> is used, the automation will close the issue(s) when the PR is merged. This is helpful when you intend to not close the issue(s), unless explicitly driven with this command.

**/close #work command**

Close linked DevRev issues with this command and the "#work" keyword, to close all related issues. The "#work" keyword means that the closure applies to all issues already associated with the Pull Request.

Bitbucket commands

Enable quick actions to close or attribute a PR to DevRev issue(s) with slash commands.

Bitbucket autonomous work

Sync Bitbucket and DevRev so issue status is always real time and driven by code.

# AWS Beanstalk

Sync DevRev issues with AWS Beanstalk and bring visibility into your deployments.

## **Overview**

![image](https://user-images.githubusercontent.com/16090899/184038023-b6211d02-e57f-4d45-b701-e69160323102.png)

Users are frequently kept in the dark about the true status of an issue. Did a commit activity that was made make it to production? Was there a production issue, and if so, was it caused by recent commits? When will it get done? How much work is left? Eliminate these questions in your team sync-ups. Let DevRev Flows answer these questions for you. Let the events from disparate systems converge.

## **How it works**

The AWS Beanstalk flow adds deployment tracking to your DevRev work items. Used in combination with VCS (GitHub, GitLab, Bitbucket) and build flows (CircleCi, GitHub Actions), you can track your work all the way from its commit to its ultimate deployment.

## **Features**

**Automatic status updates**

Automatically updates the status of work items when a related deployment succeeds.

**Record successes and failures**

Record AWS Beanstalk deployment attempts in the work items that triggered them.


AWS Beanstalk

Sync DevRev issues with AWS Beanstalk and bring visibility into your deployments.

# GitLab MR tasks

Code reviews are also work. Create a task for every GitLab Merge Request and stay on top of your code reviews.

## **Overview**

![image](https://raw.githubusercontent.com/shashankcube/image/main/gitlab-mr-task.png)

Code reviews can be time consuming — we may not always account for this in planning which may lead to poor estimates and delays. Make sure your code reviews are tracked as tasks, so you can stay on top of them.

Create tasks when you are added as a reviewer on an MR. When you enable this automation, we’ll create a task corresponding to this code review. This task is embedded in the related issue, and can also be tracked under My Tasks.

## **How it works**

To use this automation, you'll need to connect your GitLab with DevRev so we can listen to MR events. When you install this flow, we'll walk you through a few simple steps to connect and setup your reminders. You can find more on the supported connection methods here.

## **Features**

Your code reviews are also work and need to be accounted for. Use this automation to create a task for every code review, and stay on top of your GitLab MR reviews.

**Automatic MR tasks**

When a merge request is requested or reopened, a DevRev task is created for you. In order for this automation to be triggerred, you'll need to link your Merge Requests to DevRev issues. If your MR is removed, merged or closed, then the Task gets deleted. However, if you submit your MR review, then the task is closed.

## **Frequently asked questions**

<details>
<summary>What are the prerequisites for creating MR tasks?</summary>
You'll need to connect your GitLab identity with DevRev identity, so we can attribute the tasks to your DevRev user identity. You can link your GitLab identity by going to DevOrg Settings → Account → External Identities → Link GitLab Account.
</details>

GitLab MR tasks

Code reviews are also work. Create a task for every GitLab Merge Request and stay on top of your code reviews.

# GitLab MR reminder

Schedule reminders and never let your GitLab Merge Requests go stale.

## **Overview**

![image](https://raw.githubusercontent.com/shashankcube/image/main/gitlab%20mr%20reminder.png)

Stay on top of your code reviews by scheduling reminders when an MR is inactive for a certain period. You can enable this automation for all of your GitLab repos, or for specific repos. When you enable GitLab autonomous work, MR reminders are scheduled to be posted on linked issues. You may also enable the GitLab MR Task automation that creates a task for every MR.

## **How it works**

To use this automation, you'll need to connect your GitLab with DevRev so we can listen to MR events. When you install this flow, we'll walk you through a few simple steps to connect and setup your reminders. You can find more on the supported connection methods here.

## **Features**

Post reminders on your DevRev issues, when related GitLab Merge Requests are inactive for a certain period.

**Automatic MR reminders**

When a merge request is inactive for more than a specified number of days, then this automation will post a message in all related DevRev issues. You'll need to link your GitLab Merge Request to DevRev issue to enable these reminders. There are several ways to link your GitLab Merge Requests to DevRev Issues. You can do so by mentioning the DevRev issue-id in Merge Requests title or body, or mention it in the branch name or commit message. Reminders are also posted for issues created autonomously.

You can choose to setup the inactive period in number of days through the max_inactive_days setting.

## **Frequently asked questions**

<details>
<summary>What are the prerequisites for scheduling MR reminders?</summary>
This automation is triggered when Merge Requests are linked to DevRev issues. If you have not linked GitLab Merge Requests, then reminders will not be posted.
</details>

GitLab MR reminder

Schedule reminders and never let your GitLab Merge Requests go stale.