# SuperRepo Permissions

**URL:** <https://community.palantir.com/t/superrepo-permissions/7428>\
**Category:** Product Feedback\
**Tags:** superrepo\
**Created:** [October 30, 2026, 3:23pm UTC](https://community.palantir.com/t/superrepo-permissions/7428 "2026-10-30T15:23:32Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![johnmerlie](https://yyz1.discourse-cdn.com/palantir/user_avatar/community.palantir.com/johnmerlie/32/747_2.png) [@johnmerlie](https://community.palantir.com/u/johnmerlie)\
**Post date:** [October 30, 2026, 3:23pm UTC](https://community.palantir.com/t/superrepo-permissions/7428/1 "2026-10-30T15:23:32Z")

</div>

I’ve been experimenting with a SuperRepo deployment and wanted to provide some feedback on the experience. Hopefully a lot of this is already in work, but in case it’s not:

## Environment Configuration

It would be great to have a spec for what can be defined in `foundry.yml` and `env.yml`. I’ve been able to deduce a few things (e.g. mapping a group parameter to submission criteria) based on how the deployed parameters show up in the marketplace installation, but some clarity would be helpful.

## CI Deployment Job Scope

From what I can tell, the CI job token does not have a few permissions needed to leverage features supported by `@osdk/maker`:

- Creating a value type fails with a `blockSetValidationError`: `error: {blockType: VALUE_TYPE, error: ..., error: logMessage: 'ServiceException: PERMISSION_DENIED (TypeRegistry:CreateValueTypePermissionDenied)'}`
- Creating an object type with a ‘direct’ source works on the first deployment, but updating it fails with a `jobValidationError`: `{errorCode: PERMISSION_DENIED, errorName: Default:PermissionDenied, parameters: {operation: objects-data-funnel:view-direct-source-schema}}`
  - The workaround here is just to install via the UI after the version is published

## Project Tie-in

Related, but I had attempted to install the repo in one Project along with it’s store, and then deploy the installation to another project and was unable to do so. I was also unable to move an existing installation and have it successfully upgrade, neither through CI or UI.

The project installation may just be a tradeoff that’s easy enough to work around, but some additional documentation on installation patterns and mechanics would clear that up. Additionally some documentation/alignment with what features are supported where (e.g. Ontology vs. `@osdk/maker` vs. SuperRepo) would be great.

Overall, it’s a powerful tool and I think it very nicely fills a gap in the product offering. I look forward to the planned features as well!