Take a look at the documentation for the tfrun import, there are a few examples that show how one could control how policies are evaluated for an organization. The same rule applies for workspaces. One caveat is that you should always use the workspace id value and not the name.
Policy overrides are controlled through the Policy Enforcement Levels, if you wish to override policy, you need to use soft-mandatory as the enforcement level which will allow you to override the run when a policy failure occurs.
Sentinel Parameters can have a default value which is defined within the policy, or they can be defined in the Policy Set configuration in TFC/E. Terraform Cloud sends the values to the Sentinel runtime when performing policy checks on workspaces.
I am aware about the information that you posted but my requirement is bit different.
For case 1 : I should be able to enable/disable a particular policy from a policy set that is tied to all the workspaces, in such a way that one specific policy from a policy set is either enabled or disabled for a specific workspace
For case 2: Since I have a policy set tied to all the workspaces by default, I am looking for a feature where in I am able to override a specific policy from a policy set for a specific workspace.
For case 3: Since I have a policy set tied to all the workspaces by default, I am looking for a feature where in I am able to override the default parameter values (in the Tfc ui) of the policy set for a specific workspace.
Where would you like to do this? Is this something you want to manage in Terraform Cloud UI, the Sentinel Policy Set Configuration, or the Policy itself? You cannot enable/disable policies in either TFC or the Policy Set Configuration based on the workspace. We have customers that have achieved the outcome you are looking for by adding exemption handling to their policy logic. Here is a quick example that I threw together: Sentinel Playground
It may not completely solve your problem, but I think it will get you started.
Currently, this is not possible. I think this is where policy set design comes into play. Not all policy sets are globally scoped and you need to bundle certain policies into logical groups. Then you may find that you have sets that are targeted at individual workspaces. This can be quite cumbersome and sometimes it is easier to manage these kinds of requirements within the policy themselves, as shown in the example above.
Does it need to be a parameter? Could you maintain these unique values based on the workspace in a module?