Шартты мысал: есеп бағдарламасы тек белсенді клиенттерді шығарды. Интеграция қалғаны жойылды деп ойлап, CRM карточкаларын тазартуға тырысты. Сүзгі дұрыс жұмыс істеді — оның нәтижесі туралы қорытынды қате болды.
Бағдарламалар дерек алмасса, жазбаның жоғалуы нені білдіретінін алдын ала анықтаңыз. Бұл мұрағат, құқық шектеуі, тізімнің толық емес беті не шынайы жою сұрауы болуы мүмкін. «Табылмады» деген бір жауап нысан тарихын түгел түсіндірмейді.
Үш түрлі әрекетті ажыратыңыз
Мұрағаттау көбіне жазба ағымдағы жұмыста қолданылмайтынын білдіреді. Жою — өз салдары бар бөлек әрекет. Ал жүктемеде болмау бастапқы жүйеде ештеңені өзгертпеуі мүмкін.
Әр бағдарлама қолдайтын күйлерді жазыңыз. Бәріне бірдей себет не кері қайтару мүмкіндігін телімеңіз. Қажет күй жоқ болса, басқа тәсілді келісіңіз: мысалы, жауапты тексергеннен кейін әрі қарай жаңартуды тоқтату.
Қазақстандағы компания сақтау мерзімі мен жоюдың рұқсаттылығын тиісті талаптар және ішкі ережелер бойынша қажетті маманмен анықтайды. Техникалық алмасу мұндай шешімді өзі ойлап таппауы тиіс.
Пәрмен қайдан келеді
Шешім көзін белгілеңіз: нысанды өзекті емес деп кім белгілейді, бұл белгі әрі қарай беріле ме? Біржақты алмасу деректі екі жақтан автоматты жоюға міндетті емес.
Жазбаларды компания атауымен емес, тұрақты идентификатормен байланыстырыңыз. Атауы өзгереді, ал бөлек клиенттердің аты ұқсас болуы мүмкін. Не сұралды, кім растады, қандай нәтиже алынды — журналда сақтаңыз.
Жүктеме күтпеген жерден аз не бос болса, алдымен сүзгіні, беттерді, құқықтарды және байланысты тексеріңіз. Мұндай нәтижемен жаппай тазарту роботтың ерекше ынтасын емес, тоқтау мен талдауды қажет етеді.
Байланысты деректерді тексеріңіз
Карточка тапсырыстармен, хат алмасумен, файлдармен және басқа адамдармен байланысты болуы мүмкін. Салдары жүйеге, нысанға және қолданылған әдіске тәуелді.
Мысалы, Битрикс24 мәмілесін жою құжаттамасы байланысты нысандарға әсерді және нысан мен байланысты жою айырмасын ескертеді. Онда ескі әдістің өзекті алмастыру жолы да көрсетілген. Сондықтан ескі мысалдан әмбебап пәрмен көшірмей, нақты іске асырылуын тексеру керек.
Жоюды қоспас бұрын не сақталатынын, нәтижені кім көретінін және қате әрекетті қалай табатынын анықтаңыз. Экспорттың болуы тексерілген қалпына келтірумен бірдей емес.
Қауіпсіз мысалдарда сынаңыз
Оқу жазбаларының жұбын және байланысты тарихты құрыңыз. Мұрағаттауды, жоюды және сүзілген жүктемеде болмауды бөлек тексеріңіз.
Содан кейін оқу құқығын шектеп, толық емес тізімді жасаңыз. Интеграция мұны жаппай жоюдың дәлелі санамауы тиіс. Өшірілген нысанды кездейсоқ қайта құрмас үшін оқиға қайталауын және кешіккен жаңартуды сынаңыз.
Тәжірибені жұмыс дерегінде жасамаңыз. Қайтымсыз әрекеттерге алдын ала келісілген тексеру мен тоқтату тәртібі қажет.
Түзетуді неден бастауға болады
Қазіргі CRM командаға ыңғайлы болса, осы ереже үшін оны ауыстыру міндетті емес. Алдымен екі бағдарламадағы күй мен салдарды сипаттап, API — бағдарламалық алмасу интерфейстерінің — мүмкіндігін тексеріңіз.
QQDev-пен REST API интеграциясын өзгертуді талқылауға болады: жоғалған жазбаның иесіздендірілген мысалын және күтілетін әрекетті әкеліңіз. Екінші жүйенің мүмкіндігі іске асыруға уәде бермей тұрып тексеріледі. Жоюдың жақсы ережесі бос тізімнен емес, түсінікті себептен басталады.