diff --git a/doc/merging-pr-process.md b/doc/merging-pr-process.md
index e86174b951..90efa3fff6 100644
--- a/doc/merging-pr-process.md
+++ b/doc/merging-pr-process.md
@@ -4,10 +4,11 @@
 2) Add some reviewers to the PR and wait for feedback
 3) Address feedback
 4) Make sure builds and tests are green (run `make test` locally, `make lint-fix` to fix any indentation issue and `make lint`)
-5) Once the PR has been reviewed by the dev team you can run e2e tests on it by going to https://github.com/status-im/status-mobile/projects/7 and move the pr under the column E2E tests. This will trigger tests.
+5) Once the PR has been reviewed by the dev team, run e2e tests on it by going to https://github.com/status-im/status-mobile/projects/7 and move the pr under the column E2E tests. This will trigger tests. **Running E2E tests is required for all PRs.**
    1) Read our [PR Review Policy](pr-review-policy.md) for more details on our approach to PR reviews.
+   2) Learn more about our [Pipeline for QA](pipeline_process.md) process
 6) Once e2e tests have run, they will report the result on the PR, if it's less than 100%, ask QA to take a look to make sure everything is in order (some might fail for legitimate reasons)
-7) Ask QA for manual testing if the PR requires it
+7) Ask QA for manual testing if the PR requires it (more details [here](pipeline_process.md))
 8) Once it has been tested successfully, squash everything into one commit. rebase and merge. The commands we use:
 ```
   git checkout develop
diff --git a/doc/pipeline_process.md b/doc/pipeline_process.md
index a44ddce5f9..858d3d6645 100644
--- a/doc/pipeline_process.md
+++ b/doc/pipeline_process.md
@@ -1,6 +1,6 @@
 # Pipeline process
 
-[Pipeline for QA](https://github.com/status-im/status-mobile/projects/7) is a project board for developers and testers used to track the status of a pull request, get reviews and manual testing, _and run autotests_ (_temporary disabled_).
+[Pipeline for QA](https://github.com/status-im/status-mobile/projects/7) is a project board for developers and testers used to track the status of a pull request, get reviews and manual testing, and run autotests.
 
 The generally accepted recommendations for its use are described below:
 
@@ -53,7 +53,7 @@ _**How do I know if a design review is needed?**_
 
 There are three cases here depending on the changes in the PR:
 1. **Functional PRs with UI changes:** after the ```Tested - OK``` label is added, the QA moves the PR to the ```Design review``` column + mentions ```@Francesca-G``` in comments. 
-2. **Component PRs:** can be moved directly to the ```Design review``` column by the developer when get a review from devs (manual testing step can be skipped) + the developer mentions ```@Francesca-G``` in comments.
+2. **Component PRs:** once the PR has received a review from developers and e2e tests results, it can be moved directly to the ```Design review``` column by the developer (manual testing step can be skipped) + the developer mentions ```@Francesca-G``` in comments.
 3. **Functional PRs changes in which are not related to UI (e.g. a crash fix):** skip the ```Design review``` step (the PR should only be manually tested by QA).
 
 There are three possible scenarios when the design review is completed:
@@ -75,10 +75,11 @@ In the second case - after fixing of all found issues, the developer should ping
 ## Merging a PR
 **Merge conditions:**
 1. Required number of reviews received
-2. All commits are squashed into one.
-3. No conflicting files in PR
-4. No issues from lint
-5. Pay attention to automation checks (some of them are not blockers, best to check before merge anyway)
+2. E2E results are received and reviewed
+3. All commits are squashed into one.
+4. No conflicting files in PR
+5. No issues from lint
+6. Pay attention to automation checks (some of them are not blockers, best to check before merge anyway)
 ![](images/pipeline-process/automation-checks.png)