Creating a Custom Property to be used as an Account Limitation

I haven't tested, but the Usages parameter reads as if it's a Dictionary Item.

Given that assumption, you should be able to send it a hashtable of those things with true/false values.  You'd have to check on it to be sure, but I can't see why it wouldn't work.

# Possible PowerShell Example
$Usages = @{
    "IsForAlerting" = $false
    "IsForFiltering" = $true
    "IsForGrouping" = $true
    "IsForReporting" = $true
    "IsForEntityDetail" = $true
    "IsForAssetInventory" = $false
}

What happens when you build a Custom Property with "Account Limitations" checked, it adds a new entry into the Orion.LimitationTypes entity.

Now, I (personally) don't like this for any type of automation work because Orion.LimitationTypes is Read-Only and doesn't have any verbs to add things.

The way I would do it would be to create the custom property.

Build a Group based on that custom property (dynamic query is good here) and then setup the Limitation to only that single group.

For the limitations portion, you'd have to create a new account limitation using CreateLimitation verb in Orion.Limitation.

I'd do it once by hand for a throw-away account.

• Build a throwaway account (in my case "Peanut")
• Build that custom Group with only nodes that match your custom property.
• Build a limitation on that account with that definition.
  
• Review the contents of the Orion.Accounts entity to see how it's setup for that user.
  
• Review the contents of the Orion.Limitation entity to see how it's setup for that group.
  
• Review the contents of the Orion.Container (groups) to see how it's setup for that group.
  

Then you can start playing with the various verbs.  Always better to start off knowing what the data is supposed to look like each time.

I haven't tested, but the Usages parameter reads as if it's a Dictionary Item.

Given that assumption, you should be able to send it a hashtable of those things with true/false values.  You'd have to check on it to be sure, but I can't see why it wouldn't work.

# Possible PowerShell Example
$Usages = @{
    "IsForAlerting" = $false
    "IsForFiltering" = $true
    "IsForGrouping" = $true
    "IsForReporting" = $true
    "IsForEntityDetail" = $true
    "IsForAssetInventory" = $false
}

What happens when you build a Custom Property with "Account Limitations" checked, it adds a new entry into the Orion.LimitationTypes entity.

Now, I (personally) don't like this for any type of automation work because Orion.LimitationTypes is Read-Only and doesn't have any verbs to add things.

The way I would do it would be to create the custom property.

Build a Group based on that custom property (dynamic query is good here) and then setup the Limitation to only that single group.

For the limitations portion, you'd have to create a new account limitation using CreateLimitation verb in Orion.Limitation.

I'd do it once by hand for a throw-away account.

• Build a throwaway account (in my case "Peanut")
• Build that custom Group with only nodes that match your custom property.
• Build a limitation on that account with that definition.
  
• Review the contents of the Orion.Accounts entity to see how it's setup for that user.
  
• Review the contents of the Orion.Limitation entity to see how it's setup for that group.
  
• Review the contents of the Orion.Container (groups) to see how it's setup for that group.
  

Then you can start playing with the various verbs.  Always better to start off knowing what the data is supposed to look like each time.

Thanks for the suggestion, we moved to using Groups and Groups of Groups for account limitations and that works a lot better!