reasons why a sync might fail in DevRev Airdrop
ART-13117_KNOWLEDGE_NODE-0
b"Will Airdrop recreate/duplicate merged accounts or contacts?\n\nNo, Airdrop can recognize that you merged an account or contact, so it will not create them again and will keep updating any linked tickets or other linked objects.Updates from an account in the external system are not synced to DevRev, why not? I merged the account with another in DevRev.\n\nOnce you merge an account or contact, Airdrop stops syncing updates to it (just to the account or contact, not to the linked items, linked
Airdrop duplicates merging
ART-15160_KNOWLEDGE_NODE-0
b"Airdrop does not sync comments created by automations or workflows back to external systems, because such comments usually don't contain any information relevant to the external system.\n\nExamples of such comments are comments that ask users whether the issue was correctly classified. Since these are not relevant outside DevRev (and would even pollute customers' data in the external system), they are not synced in syncs to the external system."
Airdrop automation-created comment sync
ART-17216_KNOWLEDGE_NODE-6
external_sync_units: externalSyncUnits, |\n| 3 | }); |\n```\n\nor an error:\n\n```\n|  |  |\n| --- | --- |\n| 1 | await adapter.emit(ExtractorEventType.ExtractionExternalSyncUnitsError, { |\n| 2 | error: { |\n| 3 | message: "Failed to extract external sync units. Lambda timeout.", |\n| 4 | }, |\n| 5 | }); |\n```\n\n**The snap-in must always emit a single message.**\n\nTo test your changes, start a new airdrop in the DevRev App. If external sync units extraction is successful, you should be
External sync units extraction | DevRev | Docs
ART-15731_KNOWLEDGE_NODE-0
b'If the comment was created from an Agent or any other kind of system user, those comments will not get extracted and synced back. Only comments made by either a dev or rev user will get synced in reverse via Airdrop.'
Comments aren't syncing from DevRev to external system
ART-17711_KNOWLEDGE_NODE-0
b'We ran into a case where an AirSync was started by one person (Person A) and later failed. Another user (Person B) tried to click Retry, but it didn\xe2\x80\x99t work. The logs showed 401 and 403 errors in communication between the snap-in and the snap-in manager.\n\nIt turned out that AirSync assigns the sync owner to whoever started it. Since Person A had been removed from the org or lost permissions, the retry failed \xe2\x80\x94 the system still expected the original owner to have valid
Sync fails when original sync owners loses permissions
ART-17711_KNOWLEDGE_NODE-1
access.\n\nOnce Person A was re-added with the right permissions, the retry worked again.\n\nIf this happens, check who started the sync and make sure that person still exists in the org and has the right permissions. Until ownership handling is improved, retries for syncs started by users without access will fail with similar 401 or 403 errors.'
Sync fails when original sync owners loses permissions
ART-4109_KNOWLEDGE_NODE-5
Error\n\n429\n\nToo Many Requests Error\n\n500\n\nInternal Server Error\n\n503\n\nService Unavailable Error\n\nWas this page helpful?\n\nYesNo\n\n[Previous](/beta/api-reference/accounts/update)[#### Get Airdrop Sync Unit\n\nNext](/beta/api-reference/airdrop/sync-units-get)[Built with](https://buildwithfern.com/?utm_campaign=buildWith&utm_medium=docs&utm_source=developer.devrev.ai)'
Execute-Async Ai Agents Events | DevRev | Docs
ART-2035_KNOWLEDGE_NODE-57
**Slack snap-in event discussions panel** to automatically invite the DevRev app to all public channels.\n  + Private channels still require manual addition.\n\n### When sync is not possible\n\nIf sync isn\xe2\x80\x99t possible, the form will display a clear warning. Possible reasons include:\n\n* The thread is already in sync with another DevRev object.\n* Sync is not supported for the object in the given Slack channel.\n* The DevRev app is not a member of the channel.\n* The channel is
Slack | Integrate | Snap-ins | DevRev
ART-15679_KNOWLEDGE_NODE-0
b'We are querying FeedComments, which are tied to FeedItems - as you can see in this [diagram from Salesforce](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_erd_chatter.htm). In the query, we say "we want all FeedComments whose parent FeedItemId is in (all ids from FeedItem where the type is either CaseCommentPost or EmailMessageEvent)". However, when querying FeedItems Salesforce can complain that the query requires a filter by Id to work,
Why is ViewAllData permission needed for Salesforce imports
ART-15679_KNOWLEDGE_NODE-1
as is the error we get in the response: Malformed query,\xc2\xa0 FeedItem requires a filter by Id. To protect their own backend, Salesforce will not allow you to query the entire table unless you have permission to see absolutely everything that\'s in it or all the parent objects - as it makes no sense to show someone the comment to a case if they don\'t have access to cases.\n\nTo be able to query on the FeedItem table directly, we require one of the two: either you have ViewAllData
Why is ViewAllData permission needed for Salesforce imports
ART-15679_KNOWLEDGE_NODE-2
permissions or mark that Apex class as "Without Sharing". As the [Salesforce documentation for FeedItems](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_feeditem.htm) states:\n\nIf you\xe2\x80\x99re using API version 23.0 or later and have View All Data permission, you can directly query for a FeedItem. The following example returns the 20 most recent feed items.SELECT ID, CreatedDate, CreatedById, CreatedBy.FirstName,
Why is ViewAllData permission needed for Salesforce imports
ART-15679_KNOWLEDGE_NODE-3
CreatedBy.LastName, ParentId, Parent.Name, Body,\n (SELECT ID, FieldName, OldValue, NewValue FROM FeedTrackedChanges ORDER BY ID DESC) \nFROM FeedItem \nWHERE CreatedDate > LAST_MONTH \nORDER BY CreatedDate DESC\n\nWithout the ViewAllData permission we cannot efficiently query the FeedItems.'
Why is ViewAllData permission needed for Salesforce imports
ART-15661_KNOWLEDGE_NODE-0
b'The key permission requirement for Salesforce Airdrop is the "View All Data" permission. This is important to note because:\n\nThe connection owner (the user performing the Airdrop) must have the "View All Data" permission in Salesforce.\n\nImportant distinction: There is a similar permission called "View Data", which is not sufficient - you specifically need "View All Data".\n\nWithout this permission, you may encounter sync failures, particularly when trying to extract comments or feed items
Salesforce permissions requirements
ART-2053_KNOWLEDGE_NODE-67
parent-child link is created in DevRev. These types of links are skipped in the Jira loader as there is no parent link in Jira, and they are shown as skipped in reports. This link is only created once per issue.\n* Deleting and reimporting sometimes produce dead links in DevRev, which could point to non-existing issues which were deleted in AirSync settings. These links do not show up in UI, but they could be extracted, and they show up as failed in the reports.\n* Changing an epic into an
Jira Software AirSync | AirSync | Snap-ins | DevRev
ART-2053_KNOWLEDGE_NODE-64
state in Jira is not changed.\n* Comments originating from DevRev and synced to Jira are not synced back to DevRev if they are edited in Jira.\n\n### Sub-tasks\n\n* When creating a Sub-task in DevRev, the creator has to specify a parent issue in the parent field. This issue also has to be of some Jira subtype so it is synced. If the parent is empty, the Sub-task is not created in Jira, and it shows up as failed in the report under Issues column.\n\n### Epics -> Enhancements\n\nIf you choose to
Jira Software AirSync | AirSync | Snap-ins | DevRev
ART-15816_KNOWLEDGE_NODE-2
incremental sync timeframe\n\nExample:\n\nTime-scoped sync cutoff: January 1, 2024\n\nIssue A: Last updated December 2023 \xe2\x86\x92 Not imported initially\n\nLater: Issue A gets a new comment in March 2024\n\nIncremental sync imports Issue A + only the new March comment\n\nResult: All comments before January 2024 are permanently lost2. Broken Issue Links\n\nThe Problem:\n\nLinks between issues can fail if one issue was imported but the linked issue wasn't.\n\nExample:\n\nIssue X (updated
Jira Time-Scoped syncs limitations
ART-2053_KNOWLEDGE_NODE-63
type is PAT based. When creating a PAT, the user can specify the expiration date. For long running migrations, it is recommended to set the PAT to never expire, as on expiration, the PAT must be recreated manually in Jira.\n\n### Updates\n\n* If a Jira field is not writable in the creation or edit screen, AirSync may fail to create or update that issue in Jira with the corresponding change in DevRev.\n* If there is no direct transition from the current issue state to the next state in Jira, the
Jira Software AirSync | AirSync | Snap-ins | DevRev
ART-15161_KNOWLEDGE_NODE-2
settings\n\nWait for the sync to complete\n\nVerify that all articles are now showing in DevRev collections Notes\n\nArticle creation dates should be preserved from the original Zendesk articles\n\nAll accessible Zendesk articles should be imported during a successful manual sync\n\nEnsure the account used for integration has sufficient permissions to access all articles in Zendesk"
Zendesk Articles are Extracted Only During Manual Sync