Explanation on integration workflow -
1. The "Bidirectional Integration" between QMetry & JIRA is only for "Bugs" that means, if we update a bug in JIRA that will be updated in QMetry and if you update a bug from test suite execution screen or from issue module that would be updated back to JIRA. This does not work exactly for requirement in requirement module. There is "Single Directional Integrations". In case whatever we update in JIRA will come back in QMetry but what ever you update in test case module and requirement module will not go back to JIRA.
Use case is-
Ideally, you are managing your requirements in JIRA and always update JIRA so that QMetry can be in sync. OR you have stopped using JIRA for managing requirements you have imported those requirements in QMetry and moving forward you will be managing requirements in QMetry only.
2. In QMetry whatever you import from JIRA, first comes to "Issue Module" and then it comes to requirement Module or "Test Case Module". If you are deleting a particular requirement in QMetry, the correct process is - Delete it from requirement module first then delete it from issue module also. This will ensure that the particular issue is completely deleted from QMetry. Also, ensure to delete those filters which brings the same requirements from JIRA into QMetry by "multiple" filters. That means requirement comes into QMetry via single filter only. If multiple filters sync a single requirement then that particular requirement will not get update. So ensure that there are no multiple filters for same import logic.
3. The "Scope" in which you create the filter will always have the updated requirement from JIRA. So in case you do not see requirement updating from JIRA to QMetry ensure that you are looking at the correct scope in which the filter you have created OR check the domain level to see that the requirement is updated.
4. If the integration sync logs show you that a particular requirement has been sync and do not find it at cycle level that means the same copy of requirement is present somewhere in the domain and that would have been updated. Also just to cross verify, verify the issue module if that requirement is present.
5. Creating a filter for individual requirements creates multiple web-hooks in JIRA. This will add cost to performance.
For creating filters please read the article - "Ways to create Filters"
6. Suppose, You have created a filter in Sprint-1 & imported requirements. Now using "Add to other scope" you have copied those requirements into Sprint-2. If you edit/update requirement in JIRA then it will update it into Sprint-1 because the filter is created only for Sprint-1. It means requirements on Sprint-2 are at old not updated version. If you current scope is Sprint-2, then you can find the updated requirements on Domain level. You can click on "Add to Current Scope" to update the old version requirements on latest version with latest data.