Azon túl, hogy a rendszergazdák a pontosabb Vault tár keresési eredmények eléréséhez megértik és elsajátítják a keresési tokenek és keresési tulajdonságok alapjait (lásd: Vault tár keresés), módosíthatják is a felhasználók által kapott Vault keresési eredmények „tartományát” a web.config fájlban található Lucene „keresés rugalmassági tényezője” módosításával.
A „keresés rugalmassági tényezője” meghatározza, hogy a keresett kifejezés bármely két tagja között hány pozíció lehet úgy, hogy azt a program még találatnak vegye. Ezek a pozíciók a keresett karakterlánccal való teljes egyezéstől a karakterlánc bizonyos számú kombinációjáig terjednek.
A „rugalmassági tényező” egy szerkesztési távolság, ahol a távolságegység azon lépések száma, amennyivel a tokenek a lekérdezett kifejezésben elmozdulhatnak a helyükről úgy, hogy még benne legyenek a keresési eredményben. Például a keresésben lévő két szó sorrendjének felcserélése két lépést igényel. Az első lépés a szavakat egymás fölé helyezi, és a második lépés újrarendezi azokat. Tehát a két szóval vagy tokennel rendelkező keresett karakterláncok újrarendezésének engedélyezéséhez a rugalmassági tényező értékét legalább 2-re kell állítani.
Egyszerűen fogalmazva, a rugalmassági tényező határozza meg, hogy mennyire legyenek engedélyezve a soron kívüli keresési tokenek, mielőtt a program kivonná azokat a keresési eredményekből. Alapértelmezés szerint a pontosabb találatok elsőbbséget élveznek, de a keresési eredmények teljes számát ezzel az értékkel közvetlenül lehet befolyásolni.
A Web.config fájlban (C:\Program Files\Autodesk\Vault Server 20xx) keresse meg a következő két sort:
!-- slop factor provided to lucene search --> <add key="SearchSlopFactor" value="10" />
Alapértelmezés szerint a rugalmassági tényező értéke 10. Ezt az értéket 0-ig lehet csökkenteni a pontos találatokhoz, illetve bármeddig lehet növelni ezt a tartományt.
1. példa: Keresés több tokennel

Ha keresési feltételként ezt adom meg:A-055*, és a rugalmassági tényező 10-re van beállítva, sok olyan további eredményt kapok, ami hasonlít a következőhöz, és megfelel a rugalmassági tényező beállításoknak:

Ha A-055* -öt írok be keresési feltételnek, de a rugalmassági tényező = 6, pontosan ugyanezeket kapom eredményül, mert a tokenek még mindig a rugalmassági tényező által megadott „szerkesztési távolságon” belül vannak.

Ha azonban az A-055* feltételt adom meg a kereséshez, de a rugalmassági tényező = 4, az eredmények száma 5-re csökken. Nem kapom meg a B-055401-321.ipt eredményt, ennek oka pedig az, hogy a B-055401-321-A.ipt tokenjei túl messzire helyezkednek el egymástól ahhoz, hogy teljesítsék a rugalmassági korlátot, azaz a szerkesztési távolságot. Az első kötőjeltől indulva az „A”-t 5 pozícióval kellene léptetni ahhoz, hogy megfeleljen A-055*-nek.

Ha az A-055* keresési feltételt adom meg, de a rugalmassági tényező = 2, csak 4 eredmény lesz.
A B-321-055401-A.ipt ki lett hagyva, mivel az „A”-nak 3 pozíciót kellene lépnie ahhoz, hogy megfeleljen az A-055* keresési feltételnek.

Végül, ha beírom a következőt: A-055* keresési feltételként, de a rugalmassági tényező = 0, csak a pontos tokenegyezéseket kapom meg.

2. példa: Keresés kevesebb tokennel
Mi történik akkor, ha a keresést kevesebb tokennel ismétlem meg? Ezúttal a következőre fogok keresni: A055*.
Ha az A055* keresési feltételt gépelem be rugalmassági tényező = 5 érték mellett, 6 eredményt kapok, mivel hatékonyan csökkentettem azon tokenlépések számát, amelyek a találathoz szükségesek. A rugalmassági tényezőnek nem kell ilyen magasnak lennie 6 eredmény eléréséhez:

Ha az A055* keresési feltételt adom meg rugalmassági tényező = 3 értékkel, 5 eredményt kapok. A szerkesztési távolság ismét alacsonyabb, mint az előző példában, de az eredmény ugyanaz a B-055401-321-A.ipt kivételével:

Ha az A055* keresési feltételt rugalmassági tényező = 1 értékkel adom meg, csak 2 eredményt kapok.

Azonban a „-” karakter törlésével most az A055* láncot tartalmazó fájlnevek utáni keresésem rugalmassági tényező = 0 értékkel SEMMILYEN eredményt nem ad – ebben az esetben nincs pontos találat.