Technical User with "non-admin" role vs Quality seal

I am actually facing this challenge right now.

I created an automation (using a technical user associated to a role that can ONLY update a few attributes only in the Application fact sheet, using APIs, at weekly base.

But it is breaking the quality seal 😢

I wonder if there is a parameter in the API call to avoid that (or maybe an attribute we could create associated to the technical user).

OK then perhaps the user has to be ADMIN + Restricted Customer Role. The caveat is that the integration user is opened to much more than the fact sheets scopes… :-/

Unless the integration user puts back the Quality Seal to Approved, which then creates unnecessary events.

Wondering what is the best practice here… 

I may try that (ADMIN)… but I am not comfortable (I tried to remove all permissions from that custom role as possible)… but I am not sure what may still be opened (if I set it to ADMIN).

The integration should not just set it to “approved”, it should retrieve the original state and try to preserve it (too much additional work, and it may fail).

But is the Quality Seal not created so a “owner” is always in control. If somebody who is not the owner changes the data you as an owner want to be alerted so you can check if the change is correct and allowed. If there is now an other user (technical or API) that is just updating the factsheet without my consent I don't want to be held accountable anymore as an owner. 

So in your case what is the point on having a Quality Seal?

I would say there are data points that you totally want to review/approve (usually introduced by humans), and others that you trust (your automation that you implemented and tested).

In my case, those are application ‘s security vulnerability metrics (updated every week for all applications), so breaking the seal is just noise.

On my end the use case is to add to existing Apps which already have been quality-sealed. We are adding a few new attribute and relation as extra read-only data points (and to ​@abenedete’s point, already trustable). In those cases we may break the quality seal and have owners come back to approve it.

Hey great questions, 

If my technical user is a “member” (i.e.not Admin) with limited scope on only specific fact sheets and updates fact sheets using APIs, will it break the quality seal? Yes, it will always break unless you restrict the member role from breaking it.

What most customers do is they opt for self managed LX custom roles and create a replica of member role and then restrict the quality seal breakage. This is the current most effective solution for your question. 

Hi ​@justinharclerode, could you please expand on: 

What most customers do is they opt for self managed LX custom roles and create a replica of member role and then restrict the quality seal breakage. This is the current most effective solution for your question. 

So to restrict the quality seal breakage, you mean removing permissions for the custom customer_role to prevent create/update/delete on the Quality Seal?

Just confirming my understanding.

Thanks,
 

No in the backend we have an authorization model edit which we need to do. What you see in the UI is the action of setting the quality seal.

OK, got it. Can you detail the instructions on what we should be asking Support for them to perform such config? 

Thanks,

Firstly, you’ll need to enable/setup custom user roles. After than, if you haven’t already done so. Then you just create the custom role in your IDP, it will show up in LX. After you can request support to give that new role in the authorization: 

"FACT_SHEET_BASE_FIELDS:READ,UPDATE,CREATE,DELETE:*:*",

Ensure to tell them your use case.