
Sollten tatsächlich mehrere konkurrierende Anforderungen unterschiedlicher Mandanten in das Customizing einzubringen sein, so kann dies nur durch Ausprägen unterschiedlicher Objekteinträge unter unterschiedlichen Schlüsseln erfolgen.
In Extremfällen können in Mehrmandantensystemen größere Menge von Customizing-Einstellungen zur Steuerung gleicher Geschäftsprozessschritte erfasst sein. Hierdurch kann beispielsweise die Auswahl per F4-Hilfe unüberschaubar werden. Auf Seite des Providers können zur Unterstützung der Übersichtlichkeit Schlüssel-Namensräume pro Kunde festgelegt werden, sofern die Schlüsselstruktur dies zulässt.
In einigen mySAP.com-Lösungen werden bereits sogenannte Mandantenfilter eingesetzt, um pro Mandant die Menge der dort sichtbaren Customizing-Funktionen mandantengerecht reduzieren zu können. D.h. ein technisch verfügbar gemachter Eintrag ist an der transaktionalen Endbenutzerschnittstelle zunächst noch nicht sichtbar, sondern muss zunächst pro Mandant freigeschaltet werden. Die zugehörigen Filtertabellen selbst sind mandantenabhängig definiert. Bei einigen Objekten werden auch Berechtigungen als Filter benutzt. So werden in den Spooltransaktionen nur solche Drucker angezeigt, für die der User auch eine eine Berechtigung aufweisen kann, die anderen werden schon in der F4-Liste weggefiltert.
Auch für Mehrmandantensysteme gilt natürlich, dass Änderungen an mandantenübergreifenden Customizing-Einstellungen einerseits nicht durch den Endkunden, sondern nur durch den Provider vorgenommen werden dürfen. Andererseits sollten - wie auch in Einmandantensystemen - Änderungen nicht unmittelbar in der Produktivumgebung vorgenommen werden. Customizing-Einstellungen steuern Abwicklungen von Geschäftsvorfällen. Änderungen an den Einstellungen haben oft ähnliche Auswirkung auf die Transaktionslogik wie Programmänderungen und sollten daher vor ihrem Inkrafttreten in einem vorgeschalteten Entwicklungssystem durchgeführt, qualitätsgeprüft und freigegeben werden.
Es stellt sich die Frage, ob sich die Mehrmandantenstruktur in Entwicklungs-/Test-, QA- und Produktivsystem identisch wiederholen sollte, oder sich deren Komplexität in vorgeschalteten Systemen vereinfachen kann. Eine Antwort darauf ist abhängig vom betriebswirtschaftlichen Szenario: In einem ASP-Szenario mit standardisierten Geschäftsprozessen (weitgehend identisches Customizing) reicht in Entwicklungs-/Test- und und QA-System je ein (Template-) Mandant, an dem die Qualität einer Customizing-Änderung geprüft werden muss. Hingegen müssen in einem Konzernszenario mit mehreren autarken Mandanten ebensoviele Mandanten in Test- und QA-System vorhanden sein wie es unterschiedlich ausgeprägte Produktiv-Mandanten gibt.