Category
View Builder
Product Version
9.0
Multi-Org - Copy View from Main Org while in Client Org
Idea Logged
Hi,
In a multi-organization setup, there’s no native way to duplicate a main organization view while working in a client organization. The only options are manual rebuild or export/import, which are slow, error-prone, and somewhat cumbersome.
When working in a client organization, any main organization view that the user can access should be copyable into the client organization for customization. Whether a view is copyable should be controlled in the main organization via a per-view permission/flag or general rights (e.g., “allow copy to client organizations”).
Best regards,
Üllar
I like this idea 
Hello Ullar Unt,
My name is Yamini Naidu from the Yellowfin Technical Support Team. We have received your support request, and I will be your primary contact on the following ticket:
Ticket Number: #32852
Case Title: Multi-Org - Copy View from Main Org while in Client Org
Thank you for your submission of an idea request. I will review it and forward it to our development team at Yellowfin. I will ensure to keep you informed.
Sincerely,
Yamini Naidu
Yellowfin Technical Support Engineer
Hello Ullar Unt,
My name is Yamini Naidu from the Yellowfin Technical Support Team. We have received your support request, and I will be your primary contact on the following ticket:
Ticket Number: #32852
Case Title: Multi-Org - Copy View from Main Org while in Client Org
Thank you for your submission of an idea request. I will review it and forward it to our development team at Yellowfin. I will ensure to keep you informed.
Sincerely,
Yamini Naidu
Yellowfin Technical Support Engineer
Hello Ullar Unt,
This is to keep you informed that we have submitted this as an Idea request to the Product Team. As soon as we hear back from them, I will update this case for your visibility. Feel free to let us know if you have any questions or concerns; we would be more than happy to assist you.
Thank you,
Yamini Naidu
Yellowfin Technical Support
Hello Ullar Unt,
This is to keep you informed that we have submitted this as an Idea request to the Product Team. As soon as we hear back from them, I will update this case for your visibility. Feel free to let us know if you have any questions or concerns; we would be more than happy to assist you.
Thank you,
Yamini Naidu
Yellowfin Technical Support
Hello Ullar Unt,
I hope you are doing well
The following is the response from the product team regarding this request-
This restriction was implemented in Yellowfin in order to prevent users in a client org from accessing data they should not see. This can occur for example, if a View includes an access filter restriction. A copy of the view in the client org would allow the client to remove the access filter restriction, and gain access to data they should not see.
(NB. for clients using data source substitution, this is less of a concern, but Yellowfin currently cannot determine if this is the case).
Whilst it is theoretically possibly for us to build a copy feature, with appropriate safeguards, it would be useful to understand the specific use-case in a bit more detail. For example, what type of customisations are needed on the view, that requires a copy in the client org?
The reason for asking is that we have some changes currently in progress, that support dynamic customisation (for example, the ability to dynamically add custom columns to a view/report that are unique to a client org).
Regards,
Yamini Naidu
Yellowfin Technical Support
Hello Ullar Unt,
I hope you are doing well
The following is the response from the product team regarding this request-
This restriction was implemented in Yellowfin in order to prevent users in a client org from accessing data they should not see. This can occur for example, if a View includes an access filter restriction. A copy of the view in the client org would allow the client to remove the access filter restriction, and gain access to data they should not see.
(NB. for clients using data source substitution, this is less of a concern, but Yellowfin currently cannot determine if this is the case).
Whilst it is theoretically possibly for us to build a copy feature, with appropriate safeguards, it would be useful to understand the specific use-case in a bit more detail. For example, what type of customisations are needed on the view, that requires a copy in the client org?
The reason for asking is that we have some changes currently in progress, that support dynamic customisation (for example, the ability to dynamically add custom columns to a view/report that are unique to a client org).
Regards,
Yamini Naidu
Yellowfin Technical Support
Hi Yamini,
Thank you for the explanation. Could you clarify how exactly the “View includes an access filter restriction” scenario works, or what the specific use case is? From our perspective, the logic would rather suggest that this risk could be addressed by having an option in the main org to mark whether a view is copyable or not.
Also, copying a view does not necessarily mean exposing additional data as it only duplicates the structure of how the data is being pulled, not the data itself.
In our setup, the main org contains a set of standard views, which we treat as versioned templates. When updates are made over time, we overwrite them in the main org, and everything continues to function correctly. The challenge is with client orgs that require client-specific fields (e.g., special drill-downs, calculations, or similar). If we overwrite the standard view from the main org, those client-specific customisations are lost.
Additionally, due to some Yellowfin quirks, we sometimes need to create certain calculations on the view level to enable specific fields to work correctly in reports. Without the ability to copy views into client orgs, these adjustments are difficult to maintain. Managing every client-specific requirement directly in the main org would also not be feasible, as it would make the standard views overly complex and confusing.
Üllar
Hi Yamini,
Thank you for the explanation. Could you clarify how exactly the “View includes an access filter restriction” scenario works, or what the specific use case is? From our perspective, the logic would rather suggest that this risk could be addressed by having an option in the main org to mark whether a view is copyable or not.
Also, copying a view does not necessarily mean exposing additional data as it only duplicates the structure of how the data is being pulled, not the data itself.
In our setup, the main org contains a set of standard views, which we treat as versioned templates. When updates are made over time, we overwrite them in the main org, and everything continues to function correctly. The challenge is with client orgs that require client-specific fields (e.g., special drill-downs, calculations, or similar). If we overwrite the standard view from the main org, those client-specific customisations are lost.
Additionally, due to some Yellowfin quirks, we sometimes need to create certain calculations on the view level to enable specific fields to work correctly in reports. Without the ability to copy views into client orgs, these adjustments are difficult to maintain. Managing every client-specific requirement directly in the main org would also not be feasible, as it would make the standard views overly complex and confusing.
Üllar
Hello Ullar Unt,
I have forwarded your response to the product team for additional clarification. As soon as I receive any feedback from them, I will inform you with the details.
Regards,
Yamini Naidu
Yellowfin Technical Support
Hello Ullar Unt,
I have forwarded your response to the product team for additional clarification. As soon as I receive any feedback from them, I will inform you with the details.
Regards,
Yamini Naidu
Yellowfin Technical Support
Hello Ullar Unt,
I hope you are doing well
Here is the update from the product team that I wish to share-
Could you please clarify how exactly the “View includes an access filter restriction” scenario works, or what the specific use case is - many of our customers create a View in the parent org and apply an access filter restriction - https://wiki.yellowfinbi.com/space/yfcurrent/2196295/Restricting+Data+with+Access+Filters#Assign-to-a-View This access filter, may for example, restrict data that specific users can see (for example, limiting them to one company code). This method is used when a client has all data in a single logical database that all client orgs share (as opposed to using the data source substitution method).
Copying the view to the client org would allow authorised users in that view to remove that restriction and thus they could gain access to data they are not permitted to see.
If data source substitution is used then this is not an issue.
In our setup, the main org contains a set of standard views, which we treat as versioned templates. When updates are made over time, we overwrite them in the main org, and everything continues to function correctly. The challenge is with client orgs that require client-specific fields (e.g., special drill-downs, calculations, or similar). If we overwrite the standard view from the main org, those client-specific customisations are lost. - would not the same issue occur though if we built the copy feature? ie. if the master view is updated, and then re-copied to the client org, client org specific changes would still be overwritten as they would be if the export/import feature was used.
The reason for my questions is that I am trying to better understand the use case so that we can come up with the best solution. I am not sure that a copy function necessarily achieves that, but it may. I do agree that adding a “prevent copying” option to the view, would mitigate the security concern that we raised and put the onus on the administrator to set this correctly.
I am wondering if there is perhaps a more complex but ultimately more useful solution here that allows for the main view and the client org view to remain linked - and then allows for client org specific customisations to be made and tracked as such. That way the master view is maintained, changes to that master view are reflected in the client orgs automatically, but client specific customisations can also be made and would be resilient to changes in the master view. This is just a thought, and building this would be complex but interested in the clients thoughts on this.
Regards,
Yamini Naidu
Yellowfin Technical Support
Hello Ullar Unt,
I hope you are doing well
Here is the update from the product team that I wish to share-
Could you please clarify how exactly the “View includes an access filter restriction” scenario works, or what the specific use case is - many of our customers create a View in the parent org and apply an access filter restriction - https://wiki.yellowfinbi.com/space/yfcurrent/2196295/Restricting+Data+with+Access+Filters#Assign-to-a-View This access filter, may for example, restrict data that specific users can see (for example, limiting them to one company code). This method is used when a client has all data in a single logical database that all client orgs share (as opposed to using the data source substitution method).
Copying the view to the client org would allow authorised users in that view to remove that restriction and thus they could gain access to data they are not permitted to see.
If data source substitution is used then this is not an issue.
In our setup, the main org contains a set of standard views, which we treat as versioned templates. When updates are made over time, we overwrite them in the main org, and everything continues to function correctly. The challenge is with client orgs that require client-specific fields (e.g., special drill-downs, calculations, or similar). If we overwrite the standard view from the main org, those client-specific customisations are lost. - would not the same issue occur though if we built the copy feature? ie. if the master view is updated, and then re-copied to the client org, client org specific changes would still be overwritten as they would be if the export/import feature was used.
The reason for my questions is that I am trying to better understand the use case so that we can come up with the best solution. I am not sure that a copy function necessarily achieves that, but it may. I do agree that adding a “prevent copying” option to the view, would mitigate the security concern that we raised and put the onus on the administrator to set this correctly.
I am wondering if there is perhaps a more complex but ultimately more useful solution here that allows for the main view and the client org view to remain linked - and then allows for client org specific customisations to be made and tracked as such. That way the master view is maintained, changes to that master view are reflected in the client orgs automatically, but client specific customisations can also be made and would be resilient to changes in the master view. This is just a thought, and building this would be complex but interested in the clients thoughts on this.
Regards,
Yamini Naidu
Yellowfin Technical Support
Hi Yamini,
Access filters should not be a problem, since in the client org, only admins or special users have the right to modify views, and not every user can copy them. So it’s not really the case that any user could bypass restrictions. We have been using access filters for many years, and it has always worked like this: either a client org admin manages it, or we handle it ourselves.Please find comments below:
I’m not sure I understand what “re-copy” means or why this would be done. In that case, the changes would be applied in edit mode within the client org view, not by re-copying from the main org.I wouldn’t overthink this at the moment. What is really needed is just a way to avoid unnecessary export/import steps by allowing a simple copy. And then, if there is a “custom” view in the client org, that gets modified as required and is not overwritten. We have followed this practice for years in separate YF instances, and it works well.
Üllar
Hi Yamini,
Access filters should not be a problem, since in the client org, only admins or special users have the right to modify views, and not every user can copy them. So it’s not really the case that any user could bypass restrictions. We have been using access filters for many years, and it has always worked like this: either a client org admin manages it, or we handle it ourselves.Please find comments below:
I’m not sure I understand what “re-copy” means or why this would be done. In that case, the changes would be applied in edit mode within the client org view, not by re-copying from the main org.I wouldn’t overthink this at the moment. What is really needed is just a way to avoid unnecessary export/import steps by allowing a simple copy. And then, if there is a “custom” view in the client org, that gets modified as required and is not overwritten. We have followed this practice for years in separate YF instances, and it works well.
Üllar
Hello Ullar Unt,
I have forwarded your response to the product team for additional clarification. As soon as I receive any feedback from them, I will inform you with the details.
Regards,
Yamini Naidu
Yellowfin Technical Support
Hello Ullar Unt,
I have forwarded your response to the product team for additional clarification. As soon as I receive any feedback from them, I will inform you with the details.
Regards,
Yamini Naidu
Yellowfin Technical Support
Hello Ullar Unt,
I hope you are doing well
The product team is currently assessing the issue and seeks to confirm whether the expectation is that in creating a copy of the view, any reports connected to that view would have to be recreated?
Regards,
Yamini Naidu
Yellowfin Technical Support
Hello Ullar Unt,
I hope you are doing well
The product team is currently assessing the issue and seeks to confirm whether the expectation is that in creating a copy of the view, any reports connected to that view would have to be recreated?
Regards,
Yamini Naidu
Yellowfin Technical Support
Hi Yamini,
No, it’s just a simple copy of the existing view. If it’s not in a multi-org setup, it works as a straightforward view copy only. Reports connected to the original view are not copied automatically; to bring those across, you would use the export/import functionality.
Üllar
Hi Yamini,
No, it’s just a simple copy of the existing view. If it’s not in a multi-org setup, it works as a straightforward view copy only. Reports connected to the original view are not copied automatically; to bring those across, you would use the export/import functionality.
Üllar
Hello Ullar Unt,
Thank you for your prompt reply. I will relay this information to the product team. Once I obtain any feedback from them, I will update you with the specifics.
Regards,
Yamini Naidu
Yellowfin Technical Support
Hello Ullar Unt,
Thank you for your prompt reply. I will relay this information to the product team. Once I obtain any feedback from them, I will update you with the specifics.
Regards,
Yamini Naidu
Yellowfin Technical Support
Replies have been locked on this page!