Support & frequently asked questions

Hello on one site we have an strange issue with IMAPS. It is a Lotus Notes server with latest version and we use a selfsigned certificate. When we switch to IMAPS, then quite often Service is not able to load the emails. It looks, that the oldest email is blocking all the others. Some times a solution is, to delete the oldest email or move it to a different folder. But when we switch back to IMAP protocoll, then this issue does not happen.  All needed ports are open and the certificate works.  Does have anyone know similar issues and can give me a hint, what to do. Thank you! 

Have a customer with remark concerning 'archiving as task'.   I have not seen this mentioned in documentation, but before any wishlist entry:   When we archive an email as a task, we would also need to include any attachement(s) in the email that is the basis for this task. Am I missing something in existing capability, or is this a wishlist item, or should it be ?   Thank you      

Differences Between Legacy Mirroring and the New Replication Service While both solutions allow you to synchronize CRM data from the SuperOffice cloud to your local SQL database, the new Replication service introduces significant architectural and performance upgrades. . Here are the key differences you need to know:   1. Synchronization Speed (Batch vs. Stream) Mirroring (Legacy): Operates on a schedule, transferring data in batches approximately every 20 minutes . Replication (New): Operates in near real-time. It utilizes SQL Server Change Data Capture (CDC) technology on the backend to continuously stream data changes exactly as they happen . 2. Network Architecture & Security (Push vs. Pull) Mirroring (Push): SuperOffice connects to your environment and "pushes" the data. This requires you to host a public-facing Web Service (WCF/IIS), maintain a valid SSL certificate, and open incoming firewall ports . Replication (Pull): You install a local client (a Windows Service) inside your network that proactively reaches out to SuperOffice to "pull" the data. This drastically simplifies security, as you no longer need to expose public endpoints or manage incoming firewall rules . 3. Downtime and Data Retention Limits Mirroring: Can generally pick up where it left off even if your local server is down for over a week . Replication: Data changes are buffered in a cloud queue (Kafka) with a strict 7-day retention limit . If your local client is offline for more than 7 continuous days, the data expires from the buffer, and you will be required to perform a full resynchronization from scratch . 4. Tables The difference in the number of tables is completely normal and by design. The new Replication system uses the same base list of excluded tables as the old Mirroring system, but it adds a few smart improvements to keep your replica database cleaner and faster. We removed about 58 tables that don't contain reporting data: Obsolete tables: We now filter out old, leftover tables from past system upgrades (these are usually named OBSOLETE_... ). System dictionary tables: We no longer include internal system-definition tables, as they don't contain any actual customer data. Binary and Cache data: We excluded the binaryobject table because it mostly contains internal cache and large files that aren't useful for a reporting database.