Disable extension in library?

[arjan_van_wijk]

I have created a Google Analytics profile library that contain Data Layer variables, the GA tag, and some related extensions. One of the extensions has some variables in them that must be filled in from the containing site profile (e.g. a lookup table with GA accounts). Because you cannot change any value in library extensions, I can duplicate this extension and only replace the default values from the library version. Now both versions of the extension (library & duplicated) are enabled, which is not good. So I want to disable the extension in the library (indicating that it will be used for duplicating). However, when I do this, it still looks enabled in the site itself. How does this work? Or is there a better way to achieve this (without creating even more variables and extensions)?

[arjan_van_wijk]

I guess I can partly answer my own question, as the disabled library extension now correctly shows up disabled in the profile. I think it was not published correctly before for some reason, but now it works fine. I would still like to to know if this is the best way to use extensions in libraries which have values that need to be changed in the profile where it is included.

[Seth]

Honestly, if the extension has values that are specific to a profile, it's best to create a unique instance of the extension specifically for that profile. This can be time consuming with many profiles, I will admit. If you add an extension in a library, it's assumed that you don't want to change anything about that extension for your linked profiles, unless you want to change it for all of them. Currently you can't overwrite an inherited extension locally. Your suggestion from your other question (https://community.tealiumiq.com/t5/Developers/How-to-correctly-setup-Library-Architecture/m-p/6188 about allowing a user to modify an extension inherited from a library make sense to me. We do plan on revisiting profile libraries and inheritance in the future (much as we do for all of our functionality), but I can't give you any timeline on this. One thing I'd recommend is that you contact your Tealium account manager about these suggestions; direct customer feedback through our account managers is a great way to get the ball rolling on feature enhancements. Your method of duplicating a disabled library-inherited extension does work, as you've no doubt noticed. From what you've described, this does seem to be the most effective solution. But I understand that this too is cumbersome. Moreover, one thing you may run into is that when you need to change the extension in the library, you'll have to go back into the profile (which inherits that library) to re-duplicate the extension. The duplicate of the original library-inherited extension doesn't update dynamically like that. So, while you do bring in the inherited base you plan to modify in the profile, you still have that manual effort of duplication. Keep the good ideas coming though. We do appreciate feedback.

[arjan_van_wijk]

Hi Seth, thanks for responding. I know by duplicating it I still have to do changes manually in every profile, but that is something I will have to do either way :) I just want to have a place where I can put and easily include extensions that I might need several times. At the moment there can be several weeks or months between new site releases (creation of new profiles), so it's quite easy to forget which extensions you manually have to create for a profile to make a certain tag work. That's why including them in the tag library, but mark them as 'template' (disabling them, maybe also adding a TEMPLATE tag or name) will let you know what extensions to configure. The 'update once, propagate everywhere' aspect of the library is less important in this use case, because most of the values you enter are custom to a profile, so it's mostly for the 'template' aspect. I hope this makes sense :) I will also link this and the other issue to my Account Manager so they know about it.