I am trying to create a custom field on the Leads object using the metadata api. More specifically using the jsforce node module.
I can create the field just fine, but I can't query it after it's created. I have searched for a way to set field level permissions on the field using the API but I haven't found anything.
Is there a way to set field level security on a newly created custom field? Or do I have to go into the Salesforce UI to do it?
This post says that I probably need to do it from the UI.
https://developer.salesforce.com/forums/?id=9060G000000UVldQAG
But if thats the case, what good is the API then?
You can make the field level security using the metadata API. When you create a field, send the field level permission in Admin Profile type metadata.
For example,
<?xml version="1.0" encoding="UTF-8"?>
<Profile xmlns="http://soap.sforce.com/2006/04/metadata">
<fieldPermissions>
<editable>true</editable>
<field>ObjectName__c.Field__c</field>
<readable>true</readable>
</fieldPermissions>
</Profile>
Related
I have a Powerform that people sign online. I want users to be able to send that same Powerform from SFDC account object. How do I pass account id to the Powerform. I have added merge field, but it is throwing error saying subject doesn't exist.
Using the PowerForm URL, you can set tab values in the document and meta-data (Envelope Custom Fields) in the envelope.
Example: You have a tab in the template's document with the data name "accountID". The role name for the signer is signer.
Set the tab to be locked. This prevents any of the signers from changing it. (Makes it read-only.)
Create a PowerForm from the template. Receive back the PowerForm URL.
Example: https://demo.docusign.net/Member/PowerFormSigning.aspx?PowerFormId=8883&env=demo&acct=7a9312b8&v=2
Program Salesforce to send the PowerForm with the accountID set to "123":
Example: https://demo.docusign.net/Member/PowerFormSigning.aspx?PowerFormId=8883&env=demo&acct=7a9312b8&v=2&signer_UserName=Larry%20Kluger&signer_Email=larry.kluger#example.com&signer_accountID=123
In step 3, you are programming Salesforce to dynamically create a URL that includes data from the current Account object. If you don't know how to do that, ask a new question in the Salesforce stackOverflow channel.
More information
See the Programming PowerForms video.
This previous question seems similar:
Can we use merge fields(populate data from SFDC) using DocuSign Powerforms?
Does that help?
I am very new to DocuSign and trying to create a proof-of-concept for integrating DocuSign with our own Managed Package for Salesforce. I understand how I can create an envelope, how to create a document based on a template, how to fill it with the data of my Salesforce record and also how to send it.
My issue though is that the data which needs to be filled into the DocuSign document is not entirely saved within the specified record. Some data such as certain KPIs are loaded from AWS but belong to the record you're looking at. To me it seems that when creating an envelope, you need to specify the record-id of the record you're trying to pull data from.
Is it possible to extend that by not specifying a record-id but rather an Apex Object or List for example?
In my application I'm trying to use a custom user attribute, extension_Role, that should be persisted to the user during sign up.
I'd like one class of user, say "Customer" to sign-up via a mobile application and not need to provide the Role field, just default it to "Customer" behind the scenes. A second class of user will sign-up using a web app, and I'd like them to be able to select the role from a drop-down, say "Support", "Admin", etc... My plan is to provide two versions of SignUpOrSignin.xml to handle this.
Using the sample policy files Microsoft provide in the starter pack I've defined my custom ClaimType (with no UserInputType) in TrustFrameworkBase.xml and configured the client and object IDs. I've also modified the AAD-UserWriteUsingLogonEmail TechnicalProfile to persist the claim.
I'm stuck with actually persisting a default value. I've tried adding:
<OutputClaim ClaimTypeReferenceId="extension_Role" AlwaysUseDefaultValue="true" DefaultValue="Customer" />
to SignUpOrSignin.xml, however when I run the flow, I get a 500 error once I click on sign up. I think this is because it is expecting that the extension_Role field should be filled in by the user.
The only way I've been able to persist extension_Role is by adding it to the LocalAccountSignUpWithLogonEmail TechnicalProfile in TrustFrameworkBase.xml. For example:
<OutputClaim ClaimTypeReferenceId="extension_Role" DefaultValue="Customer"/>
However since this in the base file, it is shared by all login flows, which would prevent me from setting different values for different sign up flows.
What is the correct way to model this kind of dual sign-up flow?
You must specify the UserInputType when you collect information from the user by using a self-asserted technical profile. See reference here. It is why you get 500 error.
Please note that the Claim you set in SignUpOrSignin.xml (with <OutputClaim ClaimTypeReferenceId="extension_Role" AlwaysUseDefaultValue="true" DefaultValue="Customer" />) will be only returned after your sign-up at that time. The custom attribute won't be stored into Azure AD. That means when you want to query the custom attribute later, you won't find it.
So you have to set the value of extension_Role in Base policy file rather than SignUpOrSignin.xml.
In this scene, you should define two TechnicalProfiles for LocalAccountSignUpWithLogonEmail and one accepts user input, and the other one sets DefaultValue for your custom claim.
Then reference them separately from your two SignUpOrSignin.xml.
How to add custom field in existing websphere portal signup page. And where to changes for storing custom field data in database.
It all depends on what you want to add, ones that are already known to the ldap config can be easily added , go to the edit profile portlet, and configure it to add the other properties via a check box. if you want custom ones follow this
https://www.ibm.com/support/knowledgecenter/en/SSYJ99_8.5.0/admin-system/sec_subman.html
As for storing the data, you can either store as part of the user object in a property extension database(so it presents as part of the user object on login)
http://wpcertification.blogspot.com/2009/04/configuring-look-aside-database.html
Or you can extend your ldap schema and store it directly there
I am using Powerforms as an approach to get signatures using the DocuSign. What I want is to send some part of the data back to Salesforce from the PDF while the user signs it. I created custom fields on the PDF, related them to Salesforce, checked the writeback and allow sender to edit boxes but the data hasn't got back to SF yet. Any help?
When you send from Salesforce, there is information passed to document (such as the SourceID and Source Object Type), that DocuSign Connect will attempt to match to a record to process a request to push the data back into Salesforce.
If you are using a PowerForm, you would have to pass along similiar data and setup DocuSign Connect correctly for it to relate the data back to a Salesforce record.
This is something that is doable with customization, but not functional out of the box.