Hint: it’s not Fonteva, it’s your implementation
To get to the bottom of what is causing your stability issues, isolate your issues into the following categories:
Are automations failing? Is the issue confined to particular business units and business processes?
Does this happen from the community only, or never? Is it reported only by the event staff? Membership sometimes? Is it confined to certain teams? Can you replicate the issue manually? Does it happen overnight?
Are the issues confined to irregular data or missing data? Both historical and fresh?
Pull reports to verify if the data you are seeing is limited to historical records and/or originates in historical or migrated data. If you’re seeing missing data, pull reports to see how far-reaching the issue is and where it might be coming from. This is typically automation/customization or a product issue. Remember that Fonteva is a big product on top of a big product (salesforce). There’s a high likelihood that it’s in your configuration and NOT the product … that said, being clear about your investigation will help troubleshoot no matter the cause.
Do you have more than a page of system logs? Do you have a process for review? Does your organization have a consistent naming convention for flows, apex, and other automation? Are they fully elucidated that even the least-skilled user could get a hint of what they’re for? Don’t remodel a kitchen, and never do the dishes. Don’t buy a car, and never spend money on proper maintenance.
Establishing a consistent maintenance process will make spotting issues easier (read faster and therefore cheaper). A consistent naming convention helps everyone – even the developers who created them may need some reminding.
There are three buckets – Business Process bucket – does the system “work” in that it abides by your business process? Product Function bucket – does the system “work” in that a subscription is created, money is processed, and users are created. Number three is whether it “works” in that we know HOW to use it. Break down your issues and trace them as far back as you can. Replicate them if possible. Determine what training should happen as part of that process.
“We can’t trust our data!”
Lack of trust in the data is a common stability issue. This too can be divided into several categories in search of a solution.
Migrated data isn’t the same as data native to the system. It typically carries the same inconsistencies as the origin system, mapping issues, and tertiary data generated by the system, which affects downstream functions like renewals.
Are the data issues stemming from configuration/ setup. Is it consistent? Can it be replicated? If data is “missing” in a report or on a screen – go to the core record and verify that the data you’re looking for is there. If it doesn’t, follow the process back to its origins. Does the form require it? Does the code pass it?
Often, the report isn’t pulling the data correctly. It’s using the wrong data field. It’s pulling data based on when it got into the system (migrated) instead of when it happened. Understanding the data model and the reporting system can provide tremendous clarity before you throw your hands up in frustration.