SMConfig cache values coming incorrectlyIssue Post Xanadu upgrade , customers reported some of the functionalities dependent on sm config properties were brokenOn analysis , it was found that the SMConfigurationHelper api's were returning incorrect smconfig objectSymptomsFlows using SMConfigurationHelper helper api's Issue can impact multiple other flows which are dependent on smconfig property values. ReleaseXanadu +CauseRecent core api introduced SMConfigurationHelper api's to fetch smconfig . There could be one or more of below or similar causes on the instance Cause 1 : Custom code updating propertyPrefixCause 2 : Customer's have customised logic/using deprecated to fetch smconfig , Cause 3.: Cache not cleared during upgrade Resolution Issue 1 : Incorrect property prefix The issue was solved as part of Yokohama release and backported to XP7. Ideal resolution is to upgrade to XP7 and then revert the property prefix back to correct value (as mentioned below in the defect).If customer does not want to upgrade to XP7 he can update the property prefix back to original value using below background script and apply update set as mentioned in the defectTo Revert smconfig property prefix to default OOTB below is the background script (customer can modify this logic based on his affected smconfig). Also one thing before running this is to make sure the br "Prevent critical modifications on smconf" is set to false as this br would not allow the property prefix update. Once done make sure to reactivate it to trueCustomer can also update the smconfig value via update set xml's. Issue 2: Using deprecated api's The strong advice is to always use SMConfigurationHelper api's to fetch SMConfig and none other (ex SMConfigUtil, SMCoreConfigCacheManager etc). Issue 3 :Cache not cleared during upgrade : Run fix script Flush SMConfigCacheManager ( sys_script_fix_6e154ec7c3d13010a0cd587c1f40ddd1) Post issue 1 & 2 , clear cache via cache.do once the changes are done (or run above fix script) . var gr = new GlideRecord("sm_config"); gr.get("ea53ca5fd7102100bbc783e80e610394"); gr.query(); if(gr.next()){ gr.property_prefix="work.management"; gr.update(); }