Both the functions returns value 1 when a row in the MgrCode (Manager ID) column is the same as the user executing the query (@@mgrCode = USER_NAME()) or if the user executing the query is the Top Boss user USER_NAME() IN (‘userCEO’, ‘userAdmin’) and (USER_NAME() = ‘userCEO’) respectively.

CREATE SECURITY POLICY ManagerFilter
ADD FILTER PREDICATE
dbo.fn_SecurityFilterPredicateEmployee(MgrCode) ON dbo.Employee,
ADD BLOCK PREDICATE
dbo.fn_SecurityBlockPredicateEmployee(MgrCode) ON dbo.Employee
WITH (STATE = ON); -- The state must be set to ON to enable the policy.
GO
-- Now let's again check the records after applying "Row Level Security":
SELECT * FROM dbo.Employee; -- 0 rows, because my used does not have any access.
GO

Finally with the above 4 steps we’ve configured RLS with both Filter & Block predicates, to restrict unauthorized access and modification of data.

So, the ‘userHR’ account can modify his records in all 3 INSERT/UPDATE/DELETE operations. But the 4th UPDATE operation fails where he tries to update another user (‘userFin’) record. However this does not displays any error message, but the query output message clearly shows no records were updated.

And here you can see the ‘userAdmin’ account is able to update all rows belonging to other users as well, as it is configured to behave like that, and this logic is built into the Security function that we build above in Step 3.b, where the Predicate logic looks like this: