Hi @brianA32ZM. Using an external rule as a Sub routine, and passing data to it using RuleArguments is actually a pretty good idea. I have done similar tasks that way myself, but have not used that technique for this specific task. There does not appear to be any official documentation for the objects and techniques I am about to show you, but there is a pretty great Class available to us directly in our iLogic rules named "ModelStateUtils" (used without the quotes). When you type that into a rule, then type the dot after it, the built-in Intellisense system suggests a list of useful stuff you can use from there, but does not offer much in the way of hints about how they are used, or any tips about the input variables within them. This code sample below is using 3 of those tools.
ModelStateUtils.UpdateComponentDocument(oOcc)
Dim oOccMSFactoryDoc As Document = ModelStateUtils.GetFactoryDocument(oOcc)
ModelStateUtils.AssignFactoryParameter(oOccMSFactoryDoc, oOcc.ActiveModelState, sParamName, sParamValue)
ModelStateUtils.UpdateComponentDocument(oOcc)
Just in case it is not obvious, the 'oOcc' variable being used here represents a ComponentOccurrence type object in an assembly. I am attempting to update the component document both before and after attempting to make any changes to the component document, just in case the main code has already worked with another component that references the same file, but a ModelState (and therefor a different Document) within that file. I heard about that needed update in the procedure directly from an Autodesk API programmer a year or so back, but not about the specific line of code I am using here. In Line 3 of this example code, I am just using the ComponentOccurrence.ActiveModelState property to specify the name of the ModelState I want to make the parameter value change in. The alternate version of that line of code would be the ModelStateUtils.AssignTableCell() method, which has all the same inputs, but I am still not 100% sure what all the differences are between the two methods, due to no documentation available for them, and not enough time to do exhaustive testing, and report about those testing results. Keep in mind that column names within ModelStateTable are a bit odd, because if the column is for an iProperty, it will include not only the name of the iProperty, it will also include the 'nick name' of the PropertySet that the iProperty resides in, within [ & ] brackets. But nothing like that for columns for parameters.
Edit: It should also be noted that this code sequence should only be used on components that have multiple ModelStates. There is the similar ModelStatesUtil.GetModelStates(oDoc) type method available, that is supposed to return a ModelStates collection object, which we could check the Count property of, but it says it only applies to a 'factory' document. If any document has no ModelStates, or only the one original ModelState, then there is no 'factory' document, just the regular document. Once there are 2 or more ModelStates present, then the 'factory' will be the document under the control of the file's 'active' ModelState, which is not always the original (Master/Primary) one.
Wesley Crihfield

(Not an Autodesk Employee)