Hi, yes, we discussed that in this video th-cam.com/video/LfMmxnbnouk/w-d-xo.html and you can also check this one th-cam.com/video/gr2rhLCb_SM/w-d-xo.html
The only time it's NOT enabled on creation is when the create is done via Apex. When you use the UI or the REST API, it's enabled by default. I don't see us being able to have it enabled by default from Apex-again, for security reasons.
To access apex methods via postman you need to expose them in the REST API developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_rest_methods.htm
@@ragulhm named credentials have a flag that determines if they're enabled. When you create them programmatically, they are deactivated, and customers have to manually activate them. Would that work?
@@AlbaRivasSalesforce sorry for the confusion, I was expecting same usage as custom metadata, but it's fine we can make addition line of code to check weather we feature is enabled or not from custom metadata.
I would be wary of using fields like this for feature flags; protected custom settings or CMTs would be better. We might have custom field support later, but there's no ETA.
The claim that an ISV can (fully) script the creation of named credentials (and all the things these require) sounds bogus to me; we cannot include everything we need in the package, such as Auth Provider, there are expiring certificates involved, and we cannot straight-forwardly invoke the metadata API to fill in the gaps. It's a total nightmare, forcing a lot of hoops to be jumped and requiring admin post install activity (which we cannot even share through a post-install page with 2GPs).
Very interesting for CI/CD & Packaging, thanks a lot
Excelente. Gracias.
Saludos Alba,
Can we setup CI / CD pipeline with Salesforce Devops Center & Github Action.
Hi, yes, we discussed that in this video th-cam.com/video/LfMmxnbnouk/w-d-xo.html and you can also check this one th-cam.com/video/gr2rhLCb_SM/w-d-xo.html
Great stuff, Is there any way to set calloutStatus to Enabled on creation?
I don't think so, this is a security measure, to not let arbitrary code activate a credential without your permission
The only time it's NOT enabled on creation is when the create is done via Apex. When you use the UI or the REST API, it's enabled by default.
I don't see us being able to have it enabled by default from Apex-again, for security reasons.
I was looking into ConnectApi, but I cannot find any method to update the named credential. If you have any references, can you please share?
It's there! developer.salesforce.com/docs/atlas.en-us.chatterapi.meta/chatterapi/connect_resources_named_credentials_resources.htm
Updating is possible via REST; this will work for direct customers. ISVs need to wait until we have an update capability in Apex.
Excellent
Can you pls share session to access AuraEnabled Methods via Postman
To access apex methods via postman you need to expose them in the REST API developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_rest_methods.htm
Can we use light edit form to build it without apex?
Hi, not really, as they Apex code is more complex that doing a regular insert (you need to use the Connect API in Apex)
@@AlbaRivasSalesforce thanks 👍🏻 may be in future we can expect this as ISV will be very happy to build this with just LWC
I don't have anything to announce about this at the moment, sorry. Perhaps in the future; post to the Idea Exchange and see if others agree.
@@RossBelmont is it possible to create Auth provider and Link with named credentials? How can we allow browser authentication in apex?
@@ragulhm Long story short, we're going to have something else you will use for these use cases (instead of Auth Provider).
Thanks a lot, exactly in time.
Isv are gonna love it,
can we create new fields in name credentials?
Can you share the exact use case?
@@AlbaRivasSalesforce as ISV it will be helpful for us to validate a feature weather is enabled or not
@@ragulhm named credentials have a flag that determines if they're enabled. When you create them programmatically, they are deactivated, and customers have to manually activate them. Would that work?
@@AlbaRivasSalesforce sorry for the confusion, I was expecting same usage as custom metadata, but it's fine we can make addition line of code to check weather we feature is enabled or not from custom metadata.
I would be wary of using fields like this for feature flags; protected custom settings or CMTs would be better. We might have custom field support later, but there's no ETA.
The claim that an ISV can (fully) script the creation of named credentials (and all the things these require) sounds bogus to me; we cannot include everything we need in the package, such as Auth Provider, there are expiring certificates involved, and we cannot straight-forwardly invoke the metadata API to fill in the gaps. It's a total nightmare, forcing a lot of hoops to be jumped and requiring admin post install activity (which we cannot even share through a post-install page with 2GPs).