Skip to main content
Tom_R
Member
Jul 24, 2026 3:34 AM UTC
Solved

XFBR Syntax in Default Workspace, but not default maintenance unit

Hello,

I have an XFBR rule written in an assembly file in a dashboard maintenance unit that is under the default workspace, but not in the default maintenance unit.  When I try to call it using XFBR(workspace.Default.AssemblyName.BusinessRule, FunctionName,) I get an error.  If I build the same rule in a XFBR string rule under Business Rules it runs fine when called by XFBR(RuleName, FunctionName,).  Furthermore, I am not experiencing this issue for any XFBR dashboard string rule housed in an assembly in any other workspace.

Is there a different syntax that is needed to call dashboard string rules that are in an assembly in default?

As a note, the rule does not need any input parameters.

Thanks,

sameburnAnswer
Employee - Advisor
Jul 29, 2026 7:14 AM UTC

Hey ​@Tom_R 

I ran same test on v920 of platform and it works as expected for me using same named variables as your screenshot.  I believe this is a syntax error rather than a platform bug.  Please see below

  1. Maintenance Unit Setup
  1. XFBR call from Parameter.  Observe your rule is called ParamHelper not Paramhelper.  I believe this is the cause of your error (e.g. it is case sensitive as per earlier post).  If I use incorrect Paramhelper as per your example, I can replicate error

 

  1. Whereas when I use correct case-sensitive syntax e.g. ParamHelper it works as expected e.g.
  1. For completeness. my code is simple and just returning a delimited string result e.g. “True,False”

 

Hope this helps

Sam

View in thread

8 replies

Employee - Advisor
sameburnEmployee - Advisor
Employee - Advisor
Jul 27, 2026 7:24 AM UTC

Hi @TomR

I just tested this in v9.0.0 and it works as expected with both syntax examples below

  • XFBR(Workspace.Default.AssemblyName.RuleName, FunctionName)
  • XFBR(Workspace.Current.AssemblyName.RuleName, FunctionName)
1) Maintenance Unit setup under Default workspace

 

2) Label Component that returns XFBR result

Which version of Onestream are you running this on?

Sam

    Tom_RAuthor
    Member
    Jul 28, 2026 4:36 PM UTC

    I am running on version 9.2.1.18605

    My string to call the rule into the parameter is 

    XFBR(workspace.default.cmpfrm.Paramhelper, GetICInUseString,)

    What is returned is

    #ERROR XFBRworkspace.default.cmpfrm.Paramhelper, GetICInUseString,

    However, if I call the exact same rule from Business Rules it returns the expected result.

    Regards,

    Tom

    Employee - Advisor
    sameburnEmployee - Advisor
    Employee - Advisor
    Jul 28, 2026 4:44 PM UTC

    Thanks.  Have you tried case sensitive version see example below (I don’t know how your setup is actually spelt), but ensuring it 100% matches the real case of your setup

    XFBR(Workspace.Default.cmpfrm.Paramhelper, GetICInUseString)

    a screenshot of your current setup might also help demystify :)

    Tom_RAuthor
    Member
    Jul 28, 2026 4:47 PM UTC

    I have tried the case sensitive version of it, and it returns the same error.  What would you want to see in the screenshot?

    Employee - Advisor
    sameburnEmployee - Advisor
    Employee - Advisor
    Jul 28, 2026 5:02 PM UTC

    expand everything in your setup e.g. MU (like my screenshot) and then show me in a separate screenshot where you are calling the XFBR from e.g. code at call point.  I can see if i can replicate

    Tom_RAuthor
    Member
    Jul 28, 2026 9:00 PM UTC

     

    This is my set up.

    Employee - Advisor
    sameburnEmployee - AdvisorAnswer
    Employee - Advisor
    Jul 29, 2026 7:14 AM UTC

    Hey ​@Tom_R 

    I ran same test on v920 of platform and it works as expected for me using same named variables as your screenshot.  I believe this is a syntax error rather than a platform bug.  Please see below

    1. Maintenance Unit Setup
    1. XFBR call from Parameter.  Observe your rule is called ParamHelper not Paramhelper.  I believe this is the cause of your error (e.g. it is case sensitive as per earlier post).  If I use incorrect Paramhelper as per your example, I can replicate error

     

    1. Whereas when I use correct case-sensitive syntax e.g. ParamHelper it works as expected e.g.
    1. For completeness. my code is simple and just returning a delimited string result e.g. “True,False”

     

    Hope this helps

    Sam

    Tom_RAuthor
    Member
    Jul 29, 2026 1:59 PM UTC

    It does help.  I have never had the case be an issue before when calling rules.

    Thanks.

    Terms & ConditionsAccessibility statement