#315 [Feature] Principal overwriting is confusing Issue created by katrogan Motivation: Why do you think this is important? Admin overwrites the principal for recording user data like who launched an execution based on the authenticated context. But in the case of child workflows it could be argued that the principal should be derived from the parent execution metadata. Additionally, in the sdk users can explicitly specify a role at launch time but this is similarly overwritten by admin using the authenticated context. It would be simpler to unravel the authenticated context user from the principal role when recording execution metadata. Goal: What should the final outcome look like, ideally? A clearly understandable of who launched what in the execution metadata. Describe alternatives you've considered The current implementation. It gets confusing. Flyte component ☐ Overall ☐ Flyte Setup and Installation scripts ☐ Flyte Documentation ☐ Flyte communication (slack/email etc) ☑︎ FlytePropeller ☐ FlyteIDL (Flyte specification language) ☑︎ Flytekit (Python SDK) ☑︎ FlyteAdmin (Control Plane service) ☐ FlytePlugins ☐ DataCatalog ☐ FlyteStdlib (common libraries) ☐ FlyteConsole (UI) ☐ Other [Optional] Propose: Link/Inline The authenticated user from the admin context and the principal who launched an execution could be recorded as two separate fields. Additional context Is this a blocker for you to adopt Flyte cc @EngHabu flyteorg/flyte

#315 [Feature] Principal overwriting is confusing Issue closed as not planned by github-actions[bot] flyteorg/flyte