Supposons que le schéma de l'univers soit tel qu'il y ait plusieurs chemins possibles pour lier deux tables.

Ex : Soit un schéma qui inclut les notions de prêts et de commandes.
Dans ce cas, il est possible d'aller d'un client à un article via le prêt ou via la commande.

Si aucun contexte n'est défini, BO va générer automatiquement plusieurs requêtes SQL pour résoudre les problèmes dûs aux chemins multiples.

Pour notre exemple, nous avons une requête SQL pour le prêt d'un article et, une requete SQL pour la commande d'un article.

BO est capable de gérer automatiquement les problèmes de chemins multiples en associant, de manière transparente, un ensemble de requêtes SQL à la demande de l'utilisateur. Ainsi, une requête demandant à la fois le nombre de produits commandés et le nombre de produits prêtés par un client engendrera l'exécution de deux requêtes, une allant chercher les quantités commandées dans la table "commande" et l'autre les quantités prêtées dans la table "prêts".

Afin d'orienter l'utilisateur vers la requête SQL qui correspond à son besoin, on peut créer des contextes, chaque contexte désignant un chemin à choisir. Un contexte englobe donc un ensemble de jointures.

Le Designer de l'univers va définir un contexte "prêts" et un contexte "commande" en définissant les jointures associées à l'intérieur des contextes. Si l'utilisateur pose une requête ambiguë, c'est-à-dire qui ne permet pas à BusinessObjects de choisir l'un ou l'autre des contextes, le logiciel lui demandera alors le contexte associé. Cette notion de contexte permet donc d'empêcher l'utilisateur d'utiliser des jointures incohérentes en réponse à ses interrogations. Ces contextes peuvent être proposés et définis automatiquement par l'outil.

Lors de l'exécution de sa requête, l'utilisateur peut choisir un ou plusieurs contextes et donc entraîner la génération d'une ou plusieurs requêtes SQL.