Skip to main content

4 replies

harshitb6843
harshitb6843
January 25, 2023

Because the CDTs are mostly connected with tables and the security of tables is derived on a DS level. 
I agree that security on CDT could have prevented the updates of its structures but I think as now we're moving more towards record-centric apps, Appian might never implement it. 

    B
    bejjenkir0001Author
    January 25, 2023

    i agree with you , but some one edit or delete CDT columns in our same environment, that time we have facing some CDT issues , how can we protect this ,  just i am asking 

    richardn0002
    richardn0002
    January 25, 2023

    Depending on the level of access that you grant to your development team, you will either need to isolate those objects in a separate application and grant access appropriately, or by procedurally ensuring that all of the participants understand the impacts of altering core data types.

    If you are feeling particularly cautious about critical components,  you can take an export to your desktop or other secure location periodically in case you need to restore an object.  

    Good luck.

      mikes0011
      mikes0011
      Brainy
      January 25, 2023

      "CDT" is not something inherently user-facing. Like in any respect, that I can think of.  A user would only ever see data associated to a CDT (and almost never in any sort of structural sense tied directly to the CDT itself), and only ever in a site/record/interface/process that i want them to access.  I don't see any reason "security on a CDT" would even be a consideration, and would only serve to add unnecessary complexity and confusion to the already-sorta-confusing (though powerful) matrix of overlapping security settings we already have.

      The Expression Guru
        Terms & ConditionsAccessibility statement