It is possible to turn off the protections that prevent the overriding of final rules but doing so is strongly discouraged for a variety of reasons. Some of these reasons include potentially breaking the way the system works, creating an unsupported configuration that forks from the base product, and often there is an alternative way to accomplish the desired goal which does not involve overriding final rules. I would recommend that you work with GCS to discuss your situation and determine the best path forward.
I will not describe how to turn off the protections. As part of the team that does security assessments on our applications I can tell you that when we find that the protections on overriding final rules are not locked down (which we have not found in an application that is in the field) it is a significant finding. We at Pega guard the protections so seriously that they are enforced even on the development systems for our vertical and strategic applications.
I am not trying to be difficult, but we do not take making rules final lightly. When I worked as a developer on strategic application, we figured out how to circumvent the final rule protections and used it to override a few rules. It was not the right decision and the costs in the short and long term far outweighed any benefits. It is better to contact GCS and work with them to determine a solution.
What is the business problem you are trying to solve? I agree with Matt that you shouldn't be intentionally breaking your system (modifying final rules is a step beyond going outside the guardrails and puts you well into "that is not supported" territory). Often, if there is a final rule you want to modify, you can do a save as to a brand new name and call that rule. Of course that may require doing the same exercise for several rules in the chain, until you can get to what you want and their is usually a better way to solve your problem. Could you make your own harness for creating operators and work groups and then have an activity do the creation for you? I expect you could leverage much of the out of the box rules, but I'm just speculating without knowing your business requirement.
Fair warning, GCS will probably send you to consulting, since modifying final rules isn't a product defect (or if it is an attempt to address one, you'll need Pega to make the changes). It might be helpful to go back to your business requirement. We can probably help you come up with other ways to meet those requirements.
GCS actually sent me here. But I have already asked the question.
About the business requirement: it is to allow the creation of an Opertor in Pega and in another external system at the same time. And this, using the same UI that we already use to create an Operator in Pega. (so from Designer Studio)
This means that I have to add the fiels needed for the creation of the Operator Record of the external system, and fire the activity that will call the Connector for the Operator creation using the same "Create" button we already use.
I'm not sure if extending designer studio itself is the best approach. There may be extension points that would allow for the firing of an activity or data transform for the custom fields, but I doubt it. Disassembling the UI is also dangerous since you will need to redo that work for every HFix or new release that changes the rules in question. What I think you really want to do is create your own operator maintenance portal that you add to the available portals list on the access group of the operators allowed to do this. Then they can get to it from Launch in Designer Studio. This portal would be lightweight and could actually make use of the OOTB rules if they work for you and then the custom ones that you're creating via the save as suggestion I gave earlier. That will allow you to not only capture everything that you need, but also to define the post data input steps to update both the Pega Platform records and your third party system.
You can either add workgroup maintenance to the same portal or follow a similar path for that as well.